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are sent to the respective mobile systems. 
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SYSTEM AND METHOD FOR UNIFYING 
THE IMPLEMENTATION AND PROCESSING 
OF MOBILE COMMUNICATIONS AND A 

UNIFIED MOBILITY MANAGER FOR 
PROVIDING SUCH COMMUNICATIONS 5 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates in general to a system and 10 
method for unifying the implementation and processing of 
mobile communications by various mobile devices and units 
and terminals that operate on various mobile communication 
protocols and in particular to a unified mobility manager 
system and method that is used to provide such unified 15 
implementation and processing of mobile communications 
by various mobile devices and units that operate on various 
mobile communication protocols. Still more particularly, the 
present invention relates to normalizing messages from the 
various mobile devices and units and terminals, to 20 
processing, handling, and responding to these normalized 
messages, and to converting the normalized responses back 
to respective communication protocols. 

2. Description of the Related Art 25 
For the present description, the term "mobile" or "mobil- 
ity" is used to define and describe a device, unit, terminal, 

or system that is able to be moved from one location to 
another location, whether the device, unit, terminal, or 
system is a wireless system that is movable or a wireline 30 
system that is movable. Furthermore, for this present 
description, the phrase "mobile communication" or "mobil- 
ity communication" is used to define and describe commu- 
nication protocols that track movement of such "mobile" 
devices, units, terminals, or systems from one location to 35 
another location and that provide and support communica- 
tions for such "mobile" devices, units, terminals, or systems 
(i.e. whether these devices, units, terminals, or systems are 
wireless systems that are movable or wireline systems that 
are movable). As will be seen later in the specification, the 40 
present invention is not in any way limited to any particular 
communication device, unit, terminal, system, or respective 
communication protocol, and the present invention may be 
utilized with any device, unit, terminal, or system that is able 
to be moved from one location to another location (whether 45 
a wireless system or a wireline system) and with any 
communication protocol that tracks, provides, and supports 
communications for such devices, units, terminals, or sys- 
tems from one location to another location. 

In the telecommunications field, various access technolo- 50 
gies and communication protocols exist. Examples of such 
access technologies and communication protocols are 
ANSI41 (North American Cellular), Group Special Mobile 
(GSM) network, cable modem network, mobile Internet 
protocol (IP), Public Switched Telephone Network (PSTN), 55 
data network, IS- 136 Time Division Multiple Access 
(TDMA), IS-54B Time Division Multiple Access (TDMA), 
Advanced Mobile Phone System (AMPS), Code Division 
Multiple Access (CDMA), and any other such technologies 
that provide voice and data applications to a mobile cus- $0 
tomer. 

With reference now to the figures and in particular with 
reference to prior art FIG. 1, FIG. 1 illustrates that each of 
a number of conventional communication systems employ- 
ing differing technologies and protocols requires its own 65 
serving system 10 for a mobile unit or device or terminal 14 
to locate and find its own home system 12 in order to enable 
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further communication based services to be provided to the 
mobile unit or device or terminal 14 (i.e. voice related 
applications, data related applications, or any other form of 
information exchange). A home system 12 is typically where 
the subscriber or user information resides, and a serving 
system 10 is any system that provides services to and that 
registers or attempts registration of a mobile unit or device 
or terminal 14 that is outside of its home system 12 by 
finding and forwarding a request(s) to the home system 12. 
FIG, 1 shows that the mobile system 14 is away from its 
home system 12 and is at a location in which it sends its 
request to the serving system 10. The serving system 10 then 
tracks, finds, and forwards the request to the home system 12 
of the mobile system 14. The home system 12 has a home 
message processor 15 that processes the request. A response 
to the request is sent from the home message processor 15 
to the mobile system 14 through the serving system 10. 

FIG. 1 shows that each different type of mobile commu- 
nication protocol involves a mobile unit or device or termi- 
nal type that requires and accesses its respective type of 
serving system and home system. For example, ANSI41 or 
North American Cellular (NAC) is the communication pro- 
tocol for cellular communications in North America. FIG. 1 
shows that if an ANSI41 mobile unit or device 14A (i.e. 
cellular telephone or device) is away from its home area (i.e. 
home system 12A), then the ANSI41 mobile unit or device 
14A must communicate with a local and compatible ANSI41 
serving system 10 A. The local and compatible ANSI 41 
serving system 10A, in turn, finds and locates the home 
system 12A for that mobile unit or device 14A, which is an 
ANSI41 type, for the mobile unit or device 14A, and the 
serving system 10A sends a request(s) on behalf of the 
ANSI41 mobile unit or device 14A to its home system 12 A 
The home system 12Ahas an ANSI41 message processor or 
HLR 15A that is able to handle and process the ANSI41 
request and sends back a corresponding response to the 
request. 

FIG. 1 shows similar topologies for the GSM protocol, 
cable protocol, and Internet protocol (IP). For example, a 
GSM mobile unit or device 14B requires and is enabled with 
communications only through a GSM serving system 10B 
and a GSM home system 12B having a GSM message 
processor 15B that handles and processes GSM requests or 
messages. A cable modem mobile unit or device 14C simi- 
larly requires and is enabled with communications only 
through a cable modem serving system 10C and a cable 
modem home system 12C having a cable modem message 
processor 15C that handles and processes cable modem 
requests or messages, and an IP mobile unit or device 14D 
requires and is enabled with communications only through 
an IP serving system 10D and an IP home system 12D 
having an IP message processor 15D that handles and 
processes IP requests or messages. 

Thus, each individual type of communication protocol, 
such as the ones discussed above, requires its own type of 
message processor at the home system and its own separate 
hardware system for implementation. Furthermore, as 
shown in FIG. 1, the communications provided and enabled 
by the home systems 12, 12 A, 12B, 12C, and 12D are 
tracked to respective mobile systems 14, 14A, 14B, 14C, 
and 14D. However, a person who possesses mobile devices 
or units of different communication protocol types generally 
has subscriptions to the services for those types of 
communication, and these subscriptions and services require 
separate provisions of the services and usually separate 
management and billing. Presently, cross-over for process- 
ing and handling the various messages and responses for the 
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different communication protocols generally does not exist mobility management irrespective of the various access 

at this time. A system and method of unifying management technologies and protocols that exist at the home system. It 

of the various mobile communication protocols 1 , and of would still also be advantageous and desirable to unify 

tracking a person with subscriptions to services of various subscriptions of various communication services across 

mobile communication protocols do not exist. Furthermore, 5 various respective communication protocols under a single 

the unification of subscriptions of various communication umbrella for each subscriber, user, or customer, 
services across various respective communication protocols 

under a single umbrella for each subscriber, user, or cus- SUMMARY OF THE INVENTION 
tomer also does not exist at this time. 

For example, if a person owns a cellular telephone and a 30 11 * therefore one object of the present invention to 

mobile laptop computer with Internet access, then another P rovide a svstem and method for unif y m S implementa- 

person trying to reach that person has to separately dial the tion ™ d processing of mobile communications by various 

cellular telephone and separately send an e-mail message to moblle devices and units and terminals that operate on 

communicate through the mobile laptop computer. Asystem vanous mobUe communication protocols, 

and method of tracking the mobility communications of a 15 It is also another object of the present invention to provide 

person and allowing a unified manager to automatically try a unified mobility manager system and method that is used 

the various mobile communication protocols for which the to provide such unified implementation and processing of 

person has subscription^) does not exist. For example, such mobile communications by various mobile devices and units 

a method that does not exist involves a type of unified and terminals that operate on various mobile communication 

communication manager for tracking the communications 2 o protocols. 

mobility of the person by first trying to access the person's It is still a further object of the present invention to 

cellular telephone and then automatically sending the e-mail normalize messages from the various mobile devices and 

message to the person's mobile laptop computer if the units and terminals, to process, handle, and respond to these 

person was not reached by cellular telephone. normalized messages, and to convert the normalized 

Thus, each type of mobile communication protocol 25 responses back to respective communication protocols, 
requires its own separate hardware system, management, \ t & a further object of the present invention to provide a 
and provision of service. Present tracking of mobile com- unified hardware system for various types of mobile com- 
munications is generally to a mobile device or unit and is not munication protocols. 

linked in any way to a person. A person may own various h ^ m anolher object of the presem invention t0 provide 

mobile communication devices or units. In the present 30 a system and method that allow tracking of mob Ue commu- 

technology, the communications of all of the mobde systems nications t0 a person md t0 ^her subscription services for 

are each maintained and managed separately and are not yarious mobUe communication types . 

unified in any manner. A unified management of mobile , . .„ _ , , 

. u 11 *u * 1 * c ™ u*i ™ It is still a further object to unity maintenance and 

communications would allow the tracking of mobile com- _ , ..-J . J . . _ 

. . . . _ rp, . r nf management of the mobile communications that are or 

mu nications to a person. The concept or unification 01 35 . 6 . „ 

L-r. „ „ « „c various mobile communication protocol types. 

communication mobility management irrespective or the r 

various access technologies and protocols at the home It is still another object of the present invention to provide 

system presently does not exist. Furthermore, the unification unification of mobility management irrespective of the vari- 

of subscriptions of various communication services across ous access technologies and protocols that exist at the home 

various respective communication protocols under a single 40 system. 

umbrella for each subscriber, user, or customer also does not It is still also an object of the present invention to unify 

exist. subscriptions of various communication services across 

It would therefore be advantageous and desirable to various respective communication protocols under a single 

provide a system and method for unifying the implementa- umbrella for each subscriber, user, or customer, 

tion and processing of mobile communications by various 45 The foregoing objects are achieved as is now described, 

mobile devices and units and terminals that operate on A system and method for unifying and handling network 

various mobile communication protocols. It would also be messages of various communication protocols from various 

advantageous and desirable to provide a unified mobility mobile systems. The network messages are being handled at 

manager system and method that is used to provide such a home system for the various mobile systems, A gateway 

unified implementation and processing of mobile commu- 50 cluster has a number of gateways of different types of 

nications by various mobile devices and units and terminals communication protocols. The gateway cluster receives the 

that operate on various mobile communication protocols. It network messages of the respective communication pro to - 

would still be advantageous and desirable to normalize cols at the home system. The respective gateways convert 

messages from the various mobile devices and units and the network messages to normalized messages by querying 

terminals, to process, handle, and respond to these normal- 55 the categories, the data, and the network types of the 

ized messages, and to convert the normalized responses normalized data for the mobile systems from which the 

back to respective communication protocols. It would also network messages were respectively generated therefrom. A 

be advantageous and desirable to provide a unified hardware database system stores normalized data in categories. The 

system for various types of mobile communication proto- normalized data at least includes data relating to the mobile 

cols. It would also be advantageous and desirable to provide 60 systems and network types for the data. A unified mobility 

a system and method that allow tracking of mobile commu- manager is coupled to and in communications with the 

nications to a person and to his/her subscription services for gateway cluster and the database system. The unified mobil- 

various mobile communication types. It would further be ity manager receives and processes the normalized 

advantageous and desirable to unify maintenance and man- messages, performs operations based on the normalized 

agement of the mobile communications that are of various 65 messages and on the categories, the data, and the network 

mobile communication protocol types. It would still further types of the normalized data, and formulates normalized 

be advantageous and desirable to provide unification of responses responsive to the normalized messages. The nor- 
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malized responses are converted to network responses at the systems that are movable). The present invention described 

gateways and the network responses are sent to the respec- herein is not in any way limited to any particular commu- 

tive mobile systems. A normalized data structure is provided nication device, unit, terminal, system, or respective com- 

for the normalized data, and the data structure generally munication protocol, and the present invention may be 

comprises network message data, a category type for the 5 utilized with any device, unit, terminal, or system that is able 

data, and a network type that is reflective of the communi- t0 be moved from one location to another location (whether 

cation protocol from the network message. a wireless system or a wireline system) and with any 

The above as well as additional objects, features, and communication protocol that tracks, provides, and supports 

advantages of the present invention will become apparent in communications for such devices, units, terminals or sys- 

the following detailed written description. 10 terns that are movable from one location to another location. 

The present invention is a system and method for unifying 

BRIEF DESCRIPTION OF THE DRAWINGS the implementation and processing of mobile communica- 

^ , „ tl tions by various mobile devices and units and terminals 

The novel features believed characteristic of the invention ,« »\ , _ . 

, , . ~. . . „ ( mobile systems ) that operate on various mobile commu- 

are set forth in the appended claims. The invention itself 35 j ^ Qn ^ ^ Qow tQ (he fi ^ m 

however, as weU as a prefer^ particular with reference to FIG. 2, a unified mobility 

and advantages thereof, will best be understood by reference ef (UMM) 3() [s showQ ^ UMM 3() UQifies . fc _ 

to the following detailed description of an illustrative meQtation ^ processing of mobile communications by 

embodmient when read in conjunction with the accompa- mQb ^ sucfa ^ cdluIar/mobile telephones 

nying drawmgs, wherein: ^ ^ pagers ^ computers (PCs) 29B, Personal 

FIG. 1 are prior art block diagrams of vanous individual D j g j ta i Assistants (PDAs) 29C, etc., that operate on different 

and separate configurations of mobile communications mobile communication protocols, such as North American 

wherein each of the diagrams shows an individual and Cellular (NAC) or ANSI41 18, Group Special Mobile 

separate hardware system that has a mobile system which (GSM) network 20, a data network 22, a Public Switched 

uses a local serving system to locate and find its home 25 Telephone Network (PSTN), etc. The UMM 30 is also 

system in order to enable its respective type of communi- adapted to support any other future network or protocol 26 

cation protocol and provide communications for the mobile as shown in jq G> 2 . FIG. 2 shows that the UMM 30 provides 

system; a unified hardware system 30 that implements and processes 

FIG. 2 is a block diagram showing an example topology messages and provides responses for various types of mobile 

of the present invention unified mobility manager (UMM) 30 communication protocols. The UMM 30 and the system and 

used to provide unified implementation and processing of method of the present invention allow tracking of mobile 

mobile communications by various mobile systems that communications to a person and to his/her subscription 

operate on various mobile communication protocols; services for various mobile communication types. Thus, 

FIG. 3 is a chart of example categories of UMM infor- maintenance and management of the mobile communica- 

ma tion; 35 tions that are of various mobile communication protocol 

FIG. 4 is an example data organization chart for the ^P** are uri^d. 

authentication information category showing various nor- As shown in FIG. 2, the UMM 30 provides a mobility 

malized data defined for each network/personality type (i.e. manager platform that is capable of receiving messages for 

each communication protocol); different networks (such as NAC/ANSI41 18, Group Special 

^„ _ . ■ 1 * j . c Tinjfw/TTi^o 40 Mobile (GSM) network, cable modem network, mobile 

FIG. 5 is a block diagram of a UMM/UDS message . . * 1 /im ™. ui- c u -1 -r 1 u Vt ^ 1 

.u * u ji j iTA-fxj Internet protocol (IP), Public Switched Telephone Network 

processor system that handles and processes UMM mes- (psTN / data Qe \ workj IS . 136 Time Di 4 ion Multiple 

Sa ^ e T S ' , . „ , „ , ., e L , M . J Access (TDMA), IS-54B Time Division Multiple Access 

FIG. 6 is a flow chart of an algorithm for the handling and ^ Advanced Mobile Phone System (AMPS), Code 

processing of UMM messages by the UMM/UDS message 45 Diviskm Muhi le Accesg (CDMA)> and other such 

processor system and through a gateway cluster; preseQt Qr futUfe technologies that ^ able t0 track> provide) 

FIG. 7 is a chart of permanent and transient subscriber anc i support mobile communications of mobile devices, 

data used in the present invention; and umtS) terminals, or systems that move from one location to 

FIG. 8 is a chart of temporary transient subscriber data another location and that provide voice and data applications 

used in the present invention. 50 or any other information exchange to a mobile customer or 

„ user). The UMM 30 provides a unified mechanism of 

DETAILED D ^ CR IPTI O N OF I LLU STRATI VE d J flg ^ mAmy J_ ications for users / C ustomers. 

EMBODIMENT ^ UMM 3Q prov ides a logical common point for all 
For the present detailed description, the term "mobile" or mobility related messages regardless of the access mecha- 
" mobility" is used to define and describe a device, unit, 55 nism at the home system. The reuse of technology is 
terminal, or system that is able to be moved from one maximized by providing an Unified Directory Services 
location to another location, whether the device, unit, (UDS) system 31 (see FIG. 5). The UMM 30 and UDS 31 
terminal, or system is a wireless system that is movable or will be discussed in more detail later The UMM 30 and 
a wireline system that is movable. Furthermore, for this UDS 31 allow the creation of a common addressing 
present detailed description, the phrase "mobile communi- 60 mechanism, low level message parsing, state machine, etc. 
cation" or "mobility communication" is used to define and The present invention is able to provide and use context 
describe communication protocols that track movement of specific handlers as needed to support a specific protocol, 
such "mobile" devices, units, terminals, or systems from one The UMM 30 receives control messages that arrive in 
location to another location and that provide and support various networks and provide mobility management opera- 
communications for such "mobile" devices, units, terminals, 65 tions such as addressing, location, tracking of the user and 
or systems (i.e. whether these devices, units, terminals, or his/her device(s), routing, etc. The UMM 30 minimizes the 
systems are wireless systems that are movable or wireline need for separate hardware and software platforms and 
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creates a unified, consistent mechanism for services pro- 
vided to the users for mobile systems of different types of 
communication protocols. The UMM 30 provides unifica- 
tion of mobility management irrespective of the various 
access technologies and protocols that exist at the home 
system. 

FIG. 2 shows that the UMM 30 involves profile integra- 
tion and provides a common point for all mobility related 
messages regardless of access technology or protocol. The 
profile integration is the combining of various communica- 
tion protocols into a common representation or normalized 
data. The profile integration is accomplished by looking for 
common mobility management attributes in various proto- 
cols and creating an independent normalized protocol rep- 
resentation. The common point for all mobility related 
messages is provided by the UMM 30. The UMM 30 is able 
to handle the mobility related messages in two general ways: 
1) It can receive and handle all control messages in their 
respective communication protocol formats (i.e. ANSI41, 
Mobile Application Part (MAP), Mobile Internet Protocol 
(MIP), Next Generation (NG), Authentication Authorization 
and Accounting (AAA), nomadic wired mobility, or any 
other such present or future technologies that is able to track, 
provide, and support mobile communications of mobile 
devices, units, terminals, or systems that move from one 
location to another location and that provide voice and data 
applications or any other information exchange to a mobile 
customer or user) and 2) It can convert and handle all control 
messages in their respective communication formats (i.e. 
ANSI41, Mobile Application Part (MAP), Mobile Internet 
Protocol (MIP), Next Generation (NG), Authentication 
Authorization and Accounting (AAA), nomadic wired 
mobility, or any other such present or future technologies 
that is able to track, provide, and support mobile commu- 
nications of mobile devices, units, terminals, or systems that 
move from one location to another location and that provide 
voice and data applications or any other information 
exchange to a- mobile customer or user) into a normalized 
protocol that encompasses all mobility related functions and 
operations. These two options result in two respective con- 
versions: 1) Protocol conversions, where only essential 
elements required for basic mobility management of legacy 
functions are converted and 2) Mobility management 
conversion, where only essential components of legacy 
mobility management functions are ported to the new UMM 
30. 

The present invention requires the unification of the 
information that the UMM 30 needs to access to be in a 
normalized manner or fashion so that the UMM 30 is able 
to, in fact, access this data. Therefore, a unified data storage 
method is required and disclosed for the present invention. 
The information needed by the UMM 30 needs to be 
analyzed and categorized. 

With reference now to the figures and in particular with 
reference to FIG. 3, a chart 29 shows some example cat- 
egories 32 of information needed by the UMM 30. Some 
common categories 32 of UMM information for various 
access technologies or communication protocols include but 
are not limited to location tracking information 34, authen- 
tication information 36, service level agreement 38, equip- 
ment identity 40, personal information and surveillance 
information 42, authorization information 44, and terminal 
capabilities 46. The present invention is not in any way 
limited to the specific categories disclosed, and any suitable 
category may be used in conjunction with the present 
invention. 

After these common categories 32 have been established, 
data 50 pertaining to each category for each network/ 
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personality type 48 (to each category within each type of 
communication protocol) is established, maintained, and 
constantly updated. With reference now to the figures and in 
particular with reference to FIG. 4, an example data orga- 

5 nization chart 47 for the authentication information category 
36 is shown. FIG. 4 shows the chart 47 with various 
normalized data 50 defined for each network/personality 
type 48 for the authentication information category 36. The 
data 50 is normalized data which is readable and usable by 

3Q the UMM 30. For example, the chart 47 shows that for the 
network/personality of ANSI41 18 (such as for a cellular 
telephone), the normalized data 50 for the authentication 
information 36 is defined as Authentication Algorithm Ver- 
sion (AAV), Authentication Capability (AuthCap), Authen- 
tication Key (Akey), and Signaling and Messaging Encryp- 

15 tion (SME) (NAC) wherein this normalized data 50 is used 
by the UMM 30 in order to handle and process authentica- 
tion information for an ANSI41 network/personality. The 
chart 47 further shows that for the cable network/personality 
(such as for cable modem), the normalized data 50 for the 

20 authentication information 36 is defined as Cable Modem 
specific authorization wherein this normalized data 50 is 
used by the UMM 30 in order to handle and process 
authentication information for a cable network/personality. 
The chart 47 also shows that for the network/personality of 

25 GSM 20 or GSM GPRS, the normalized data 50 for the 
authentication information 36 is defined as Authentication 
(Auth.) triplets, Random Number (RAND/SRES), and 
Authentication Key (Kc) wherein this normalized data 50 is 
used by the UMM 30 in order to handle and process 

30 authentication information for a GSM or GSM/GPRS net- 
work or personality. The chart 47 still further shows that for 
the mobile' IP network/personality (such as for a mobile 
computer with IP access), the normalized data 50 for authen- 
tication information 36 is defined as Authentication Certifi- 

35 cates (Auth. Certificates) and encryption key wherein this 
normalized data 50 is used by the UMM 30 in order to 
handle and process authentication information for a mobile 
IP network/personality. Other charts similar to chart 47 
would exist for the other categories (i.e. location tracking, 

40 service level agreement, equipment identity, personal infor- 
mation and surveillance information, authorization 
information, terminal capabilities, etc.) for correlating nor- 
malized data for each category to respective networks/ 
personalities. The present invention is not in any way limited 

45 to the specific data category, network/personality, organiza- 
tion or normalization of data disclosed, and any suitable 
category, network/personality, data organization or normal- 
ization of data is able to be used in conjunction with the 
present invention. Furthermore, any present or future com- 

50 munication protocol that requires mobility management and 
that tracks, supports, and provides communications of a 
mobile device, unit, terminal, or system, whether it is a 
wireless system or a wireline or wired system, is able to be 
used in conjunction with the present invention. 

55 Thus, all information pertaining to the various networks/ 
personalities are stored in the same or similar format as 
illustrated in the example of FIG. 4. The generic represen- 
tation of the format (as illustrated in chart 47 of FIG. 4) is 
as follows: network/personality type followed by the data 

60 for that network/personality type. The identification and 
correlation of the network/personality type to the data allows 
conversion from the network specific messages to normal- 
ized data and vice versa as well. Any data that is already 
common to all networks is unlabelled and is able to be 

65 extracted and directly accessed for all network types. 

With reference now to the figures and in particular with 
reference to FIG. 5, the Unified Mobility Manager/Unified 
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Directory Services (UMM/UDS) message processor system system 14 of the user needs. An example of how the UDS 
72 that handles and processes UMM messages that were data 96 is organized in the UDS 31 is shown in chart 95. The 
converted from network specific messages is shown. Refer- UDS data 96 may include the identification of the user 97. 
ring to FIGS. 1 and 5, the UMM/UDS message processor For that user 97, the network specific user identification (ID) 
system 72 is located in the home system 12 and replaces the 5 98, the location information 100, and other such information 
home message processor 15 located therein. Referring to may be identified. The fifth step of the method, which 
FIG. 5, the UMM/UDS message processor system 72 com- generally occurs at location 92, involves the UMM 30 
prises three main sub-systems: the gateway cluster 74, the sending an intended response in the normalized manner to 
Unified Mobility Manager (UMM) 30, and the Unified the appropriate and respective gateway within the gateway 
Directory Services (UDS) 31. The gateway cluster 74 com- 10 duster 74. The respective gateway then converts the nor- 
prises a number of gateways for various communication malized response back to the corresponding communication 
protocols (i.e. networks/personalities 48). These gateways P rotoco1 (jf ■ network/personality), which provides a net- 
receive network specific messages from the serving system work s P ecific res P on f e - ^ e sixth step of the method which 
10 (i.e. see block diagram 5 of FIG. 1). The UMM 30 S enerall y occure at l° catl °n 94 > ves sending the con- 
, f „ # , , verted network specific response back through the serving 
manages, retrieves, and perfoms aU operaUons requested by 1S w an(J ^ ^ * f ^ 

network specific messages. The UDS 31 allows respective ^ ^ $ of nG _ 1} 

operations to be performed on it by the UMM 30, and the 117 .,, c . a j - 1 -,l 

ttt^o n i- n flL • c ;• j j . 4 i tnfW With reference now to the figures and in particular with 

UDS 31 supplies all of the ^formation needed to the UMM refereQce tQ RG 6 a flow ^ rf m $2 for 

30 by supplying the Network Specific Identifier (NSI), the handlin and processiQg of UMM messages by the UMM/ 

Network Transparent Identifier (NTI), and the specific 20 UDS message processor system 72 and through a gateway 

network/personality type 48 along with any common infer- cluster 74 and for accessing the normalized data in the UDS 

mation that the user needs. 31 ^ shown. The algorithm 52 starts at block 54. The 

The present invention involves the implementation of a algorithm 52 moves to block 56 where a network specific 

UMM message processing and handling method, which is message (i.e. from the serving system 10 as shown in FIG. 

illustrated in FIG. 5. The first step of the method, which 25 1) is received at the UMM 30. The network specific message 

generally occurs at location 84, involves the network spe- contains a network specific identity (NSI). The algorithm 52 

cific messages being received by the gateway cluster 74 and moves to block 58 where the UMM 30 translates this 

directed to respective types of gateways depending on the message from a NSI to a network transparent identifier 

type of messages received. For example, if a specific (NTI) by querying the UDS 31. At this step at block 58, a 

ANSI41 or NAC message is received at the gateway cluster 30 simple unique match is generally sought. The algorithm 52 

74, then the message is forwarded, normalized, and pro- moves to block 60. At block 60, the UMM 30 constructs a 

cessed by the ANSI41 or NAC gateway 76. If a specific normalized query for retrieving data using the NTI specified 

GSM message is received at the gateway cluster 74, then the and a network/personality type 48, which is derived from the 

message is forwarded, normalized, and processed by the NSI of the network specific message. The algorithm 52 

GSM gateway 78. If a specific Mobile Internet Protocol 35 moves to block 62 where the UDS 31 returns all of the 

(MIP) message is received at the gateway cluster 74, then information pertaining to the NTI in response to the network 

the message is forwarded, normalized, and processed by the specific message. The algorithm 52 moves to block 64 where 

MIP gateway 76. This step of processing messages is the information is parsed to extract the network/personality 

performed in the same manner for any other types of specific attributes or data. The algorithm 52 moves to block 

messages at respective types of gateways. The second step 40 66 where the extracted data which constructs the network 

of the method, which occurs at location 86, involves con- specific response for a network/personality type 48 is sent 

verting the network specific identities of the specific mes- from the UMM 31 to the gateway cluster 74 and to the 

sage to a network transparent identifier (NTI). The respec- appropriate and respective gateway. The algorithm 52 ends 

tive gateway performs the conversion, and the conversion is and stops at block 68. 

accomplished by looking up a conversion table of 45 The present invention provides unification of subscrip- 

information, such as a local cache or UDS lookup table (i.e. tions of various communication services across various 

conversion table may be derived from category charts, such respective communication protocols under a single umbrella 

as the chart 36 in FIG. 4). The conversion is generally from for each subscriber, user, or customer. A user may have 

a Network Specific Identity (NSI) to a Network Non-specific mobile devices, units, or terminals in which respective 

Identity (NN1) with generic operations requested such as 50 subscriptions to services for these devices, units, or termi- 

add, update, search, delete entries, etc. The normalized nals have been obtained, and the mobile devices or units or 

message having the NTI is forwarded to the UMM 30. The terminals are of different types of communication protocols, 

third step of the method, which generally occurs at location The present invention, which includes the gateway cluster 

88, involves the UMM 30 processing the normalized mes- 74, the UMM 30, and the UDS 31 at the home system 12 that 

sage and then performing the appropriate operation on the 55 processes network specific messages, may be implemented 

UDS 31. The information that is needed from the UDS 31 is and used to track the various mobile communications of a 

obtained by supplying the Network Specific Identifier (NSI) user instead of the mobile systems or mobile devices, units, 

along with the Network Transparent Identifier (NTI) and the or terminals themselves. The normalized data provides a 

specific network/personality type 48. way for tracking all of the mobile communication protocols 

The fourth step of the UMM message processing method, 60 and mobile systems utilized by the user since all of the data 

which generally occurs at location 90, involves the UMM 30 is able to be stored in an unified manner (i.e. in a unified 

retrieving and performing all the operation^) requested by . storage system and handled by a unified data manager), that 

the network specific message that was/were from the mobile is, respectively UDS 31 and UMM 30. All of the information 

system 14 of the user. The UDS 31 searches through the for a user and his/her mobile systems able to be stored as 

unified or normalized data to look for any information 65 normalized data in the UDS 31. 

pertaining to the user using the NSI and network/personality With reference now to the figures and in particular with 

type 48 along with any common information that the mobile reference to FIG. 7, a chart of permanent and transient 
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subscriber data 102, which is an example of normalized data 
for the present invention, is shown. FIG. 7 shows an 
example organization and format for the different types of 
permanent and transient data 102. The permanent and tran- 
sient subscriber data 102 includes but is not limited to the 5 
following: 1) Top level User Identity 104 (i.e. Person, 
UserNAI, etc.); 2) User Identity/Terminal Identity 106 (i.e. 
NAI, IMSI, MI, and IP addresses); 3) Equipment Identity 
108 (i.e. Serial Number (GSM and NAC), PC Identity 
(MAC Address), Intel Chip ID); 4) Personal Information 110 10 
(i.e. name, address, etc.); 5) Service Level Agreements 
(SLA) 112; 6) Terminal capabilities/network capabw'ties 114 
(i.e. Access specific or technology specific (IP enabled or 
access enabled)); 7) Location Information 116 (macro 
location) (i.e. COA (IP address of subnet), MSC ID (NAC is 
only), MSC Number, VLR, SGSN Number (GSM), LSF 
NAI (IPM specific)); 8) Authentication Information 118 (i.e. 
AAV, AuthCap Akey, SME (NAC), Authentication 
Certificates, IPSec, IKE, AAV, Encryption key, etc. (IP 
networks),. Security Parameter Index (SPI), Authentication 20 
triplets, RAND/SRES, and Kc (GSM network)); 9) Autho- 
rization 120 (i.e. Authorization Period, Geographic Autho- 
rization (NAC), RSZI lists, Call barring restrictions based on 
location/roaming, subscription restriction, etc., IP enabled 
networks (such as firewall, lifetime, subnets enabled)); 10) 25 
Surveillance and Call Trace 122 (i.e. GSM, NAC, IP, etc.); 
11) Services 124 (i.e. Quality of Service Profile (such as 
GPRS, MIP, lxRTT MIP), Origination services (such as 
local, national, toll, etc.), Termination services (such as 
forwarding services, conferencing, data delivery, call/data 30 
screening), Roaming services (such as location based ser- 
vices and restrictions, etc.). 

With reference now to the figures and in particular with 
reference to FIG. 8, a chart of temporary transient subscriber 
data, which is another example of normalized data, is shown. 35 
FIG. 8 shows an example organization and format for the 
different types of temporary transient data 126. The tempo- 
rary subscriber data 126 includes but is not limited to the 
following: 1) Micro level mobility information of the 
mobile/terminal 128; 2) Temporary transient information 40 
130, which needs to be updated frequently where the UDS 
31 may not be used (i.e. Location Area ID, Control channel 
data, mobile not reachable flag (NAC), MS Purged for 
GPRS, SGSN area restricted flag, etc. for GSM, MIP/lxrTT 
such as co-located address flag, broadcast data grams, 45 
identification). 

While the invention has been particularly shown and 
described with reference to a preferred embodiment,. it will 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 50 
from the spirit and scope of the invention. 

What is claimed is: 

1. A method of unifying and handling network messages 
of various communication protocols from various mobile 
systems wherein the network messages are being handled at 55 
a home system for the various mobile systems comprising 
the steps of: 

storing normalized data which at least includes data 
relating to the mobile systems and network types of the 6Q 
mobile systems correlated to the data wherein the 
normalized data are stored in categories in a database 
system, 

receiving the network messages at the home system, 
converting the network messages to normalized messages 65 
by querying the categories, the data, and the network 
types of the normalized data for the mobile systems 
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from which the network messages were respectively 
generated therefrom, 

processing the normalized messages and performing 
operations based on the normalized messages and 
based on the categories, the data, and the network types 
of the normalized data, 

formulating normalized responses responsive to the nor- 
malized messages, 

converting the normalized responses to network 
responses, and 

sending the network responses to the respective mobile 
systems. 

2. The method according to claim 1, wherein the step of 
storing normalized data further comprises the step of: 

storing the normalized data in a unified directory services 
system. 

3. The method according to claim 1, wherein the step of 
receiving the network messages further comprises the steps 
of: 

receiving the network messages at a gateway cluster that 
has a number of gateways for different types of com- 
munication protocols, 

determining the different types of communication proto- 
cols for the network messages, and 

directing each of the network messages to a respective 
one of the gateways based on each of the determined 
different types of communication protocols for the each 
of the network messages. 

4. The method according to claim 3, wherein the convert- 
ing steps are performed at the gateways. 

5. The method according to claim 1, wherein the network 
messages contain network specific identities and wherein the 
step of converting the network messages further comprises 
the step of: 

converting the network specific identities of the network 
messages to network transparent identifiers. 

6. The method according to claim 5, wherein the step of 
converting the network specific identities further comprises 
the steps of: 

providing lookup tables in the database system for the 

categories, and 
using the lookup tables to convert the network specific 

identities to the network transparent identifiers. 

7. The method according to claim 1, wherein the step of 
processing the normalized messages further comprises the 
steps of: 

forwarding the normalized messages to a unified mobility 
manager, and 

using the unified mobility manager to perform appropriate 
operations on the database system. 

8. The method according to claim 7, wherein the network 
messages contain network specific identities and wherein the 
step of converting the network messages further comprises 
the step of converting the network specific identities of the 
network messages to network transparent identifiers and 
wherein the step of using the unified mobility manager 
further comprises the step of: 

obtaining information needed for performing the appro- 
priate operations by supplying the network specific 
identities along with the network transparent identifiers 
and the network types to the database system. 

9. The method according to claim 1, wherein the step of 
processing the normalized messages further comprises the 
steps of: 

using a unified mobility manager for retrieving and per- 
forming the appropriate operations, and 
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having the database system search through the normalized convert the network specific identities to the network trans- 
data to look for information relating to the mobile parent identifiers. 

systems. 16. The system according to claim 11, wherein the unified 

10. The method according to claim 9, wherein the network mobility manager performs appropriate operations on the 
messages contain network specific identities and wherein the 5 database system. 

step of converting the network messages further comprises 17. The system according to claim 16, wherein the net- 

the step of converting the network specific identities of the work messages contain network specific identities and 

network messages to network transparent identifiers and wherein the gateways convert the network specific identities 

wherein the step of having the database system search of the network messages to network transparent identifiers 

further comprises the step of: 10 and wherein the unified mobility manager obtains informa- 

using the network specific identities, the network types, tion needed for performing the appropriate operations by 

and common information for finding the information supplying the network specific identities along with the 

relating to the mobile systems. network transparent identifiers and the network types to the 

11. A system for unifying and handling network messages database system. 

of various communication protocols from various mobile " 18 ne svstem according to claim 11, wherein the unified 

systems wherein the network messages are being handled at mobility manager is used for retrieving and performing the 

a home system for the various mobile systems comprising: appropriate operations and the database system searches 

, t . . . c c j-r through the normalized data to look for information relating 

a gateway cluster having a number of gateways of dif- t . 

% J - & . 4 . to the mobile systems. 

ferent types of communication protocols for receiving mm. / _j- * i • m u a. 
. Jr . • 20 19. The system according to claim 18, wherein the net- 

the network messages of the respective communication , ' . • * i j a 

. , & j r iL work messages contain network specific identities and 

protocols at the home system and for converting the • • * _ t . J * a a 

r J , , & A wherein the gateways convert the network specific identities 

network messages to normahzed messages at the gate- of ^ me > tQ network t 7 rent identifiets 

ways by querying the categories, the data, and the . . . . , . ,° , .u * i c 

J / ^ J * ,. , . r ' ... and wherein the database system uses the network specific 

network types of the normalized data tor the mobile . ... * . j . c J c 

, 7 .7 . tL . 25 identities, the network types, and common information for 

systems from which the network messages were fi ^ mformation ^ tQ the mobile ms 

respectively generated therefrom, ^ nonnalizcd dala stm ^ ture ^ for and 

a database system for storing normalized data in catego- handling one of a number of network messages based on one 

ries wherein the normalized data at least includes data of a number of communication protocols from various 

relating to the mobile systems and network types of the 3Q mobile S y Stems wherein the network messages are being 

mobile systems correlated to the data, handled at a home system for the various mobile systems, 

a unified mobility manager coupled to and in communi- said normalized data structure comprising: 
cations with the gateway cluster and the database d a t a storage including: 

system wherein the unified mobility manager receives data from the one of the network messages, 

and processes the normalized messages, performs 35 0 ne of a number of data categories for identifying a 
operations based on the normalized messages and category type of the data, said data categories includ- 

based on the categories, the data, and the network types mg location tracking information, service level 

of the normalized data, and formulates normalized agreement, personal information and terminal 

responses responsive to the normalized messages, and capabilities, and 

wherein the normalized responses are converted to net- 40 one of a number of network types that identifies and 
work responses at the gateways and the network correlates the respective one of the communication 

responses are sent to the respective mobile systems. protocols to the data. 

12. The system according to claim 11, wherein the data- 21. The normalized data structure according to claim 20, 
base system is a unified directory services system. wherein the data categories further include authentication 

13. The system according to claim 11, wherein the respec- 45 information, equipment identity, surveillance information, 
tive gateways determine the different types of communica- and authorization information. 

tion protocols for the network messages and direct each of 22. The normalized data structure according to claim 20, 

the network messages to a respective one of the gateways wherein the network types include at least two network 

based on each of the determined different types of commu- types among: a NAC/ANSI41 network, a Group Special 

nicatioo protocols for the each of the network messages. 50 Mobile (GSM) network, a cable modem network, a mobile 

14. The system according to claim 11, wherein the net- Internet protocol (IP), a public switched telephone network 
work messages contain network specific identities and the (PSTN), a data network, an IS- 136 time division multiple 
gateways convert the network specific identities of the access (TDM A), an IS-54B time division multiple access 
network messages to network transparent identifiers. (TDM A), an advanced mobile phone system (AMPS), and a 

15. The system according to claim 14, wherein the data- 55 code division multiple access (CDMA), 
base system comprises lookup tables for the categories 

wherein the lookup tables are used by the gateways to ***** 
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ABSTRACT 



A system including a client database for managing conver- 
sation threads generated from messages communicated in a 
client-server achitecture is disclosed. The client database 
efficiently manages messages and optimizes communication 
between the client and server. In a specific embodiment, the 
messages include email messages from a SMTP server and 
news messages from a NNTP server. The conversation 
threads are generated for use in a MAPI form at -sensitive 
application. The client database maintains a central archive 
of message -related information to support conversation 
threading of current and future messages downloaded from 
the server to the client. The client database supports efficient 
management of conversations so that conversation roots and 
nested replies are presented sequentially. When a message 
refers to another, unreceived message, the system creates a 
placeholder for the unreceived message in the client data- 
base. Using a placeholder eliminates the need to rethread all 
conversations after every download. The database includes 
data fields corresponding to specific fields of a typical MAPI 
format. The database also includes data fields to assist in 
providing more efficient and timely operation of retrieving 
and threading conversations from a local message store, 
such as a MAPI store. News messages can also be converted 
from a news conversation threading structure to a MAPI 
format. 

30 Claims, 14 Drawing Sheets 
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SYSTEM AND METHOD FOR USING A Other systems have managed conversation threading by 

CLIENT DATABASE TO MANAGE generating a conversation index. The conversation index 

CONVERSATION THREADS GENERATED consists of a preamble for uniquely identifying the conver- 

FROM EMAIL OR NEWS MESSAGES sation root and additional parameters for each child of the 

T-cr^LiMT^AT ttict n 5 conversation r00t - 1° this conversation threading scheme, a 

JtUHiNiu/VL ?it.w group of related messages making up a conversation gen- 

The present invention relates to communication and stor- erally have the same preamble. The parameters for related 

age of electronic mail messages, and more particularly reply messages, whether a reply message is linked to the 

relates to managing conversation threads by using a client- conversation root or another reply message, are derived from 

based database. 10 the conversation root. In this way, the group of related 

BACKGROUND OF THE INVENTION messages are linked to each other and message order can be 

maintained. 

Electronic mail (e-mail) is one of the most commonly nf , .. . . . . , , # . 

, ... r x /., . . . ' Oftentimes in these prior systems, the integrity of the 

used applications for distributed computer networks. The , . / , . , . .J r , 4 , 

u «. c -1 r t i message order can be difficult to maintain if all related 

benefits of e-mail applications are numerous. Users can & * . • j . *■ j ■ jij 

... ■ / * t t. 4 . Tf t 15 messages are not retrieved at one time during a download 

quickly communicate with one another. If a user is not J QD ^ ^ ^ , ^ tbese 

available to pick up a message immediately, the message is s £ tems fflust rethfead a „ eomma&m ^ 

stored until that user can review the stored message at a later J j ij , . • n j 

« , . , • i j . every download operation. These systems typically do not 

time E-mail messages also provide a quick and easy way to ' ^ for ^ tha , m 0(der 

package information such as sales reports graphics, and 20 can maintained and * essage * do not have t0 reth . 

other data for transfer to another user by simply attaching the reac jed 
information to the message. These days, business users 

increasingly rely on e-mail messages to share ideas, transmit Another problem resulting from prior systems using dif- 

documents, schedule meetings, and perform a multitude of fereDt conversation threading schemes is converting one 

other everyday tasks conversation threading scheme to another. For example, 

These tasks may be accomplished by a variety of software * so , me ^ems use a MAPI format where messages stored in 

m c „ ' i„ n ' f n „;ut n *~ a local message store, such as a MAPI store, are threaded by 

programs, hor example, e-mail programs facilitate the trans- & . . , « w * r 

*. • p „ . . * , » - ■ a „ . , , generating a conversation index. The MAPI to rm at cannot 

mission of messages between users. Messaging-enabled r « . ■ . ■ n r 

, , ,. „ 11 „ * . j handle news messages, which are typically formatted in a 

scheduling programs allow users to request and schedule iT & ' , J * 3 , , 

j . 4*1*- tree structure. Not onlv are these systems unable to accom- 

meetmgs and appointments via electronic messages. Com- 30 auuwiui*. «^ ^^wa uuaun, iu av^iu 

puter programs known as desktop information managers modate % news messa § e * a tree structure > the y do DOt ha ? 

attempt to coordinate the growing stream of electronic a means for converting the news message to a compatible 

communications by incorporating e-mail, a calendar, task conversation threading scheme. 

management, contact management, notes, and journal fea- Therefore, there is a need for a system that optimizes 

tures into a single application program. 35 communication with electronic mail servers. There is also a 

The increased reliance on electronic messaging has need for a sin S le mechanism for managing messages on a 

resulted in a great increase in the number of electronic user ' s local message store. There is a need for a system that 

messages a user sends and receives daily. These messages 15 able to accommodate news messages. In addition, there is 

can include news messages, as well as general mail mes- a need for a svstem mat effectively and efficiently keeps 

sages. Users who send and receive a large number of e-mail 40 track of messa S es that are downloaded from a server to a 

messages would like an effective way to process their e-mail chent - Mso > there 1S a need for a s y slem that 15 able t0 

without spending a lot of time sorting through their in-box, maintain the message order of a threaded conversation, 

deleting, filing, forwarding, and responding to their mes- ™ ere * an additional need for a system that is able to 

sages. Hence, a major problem with e-mail is that a user can convert one conversation threading scheme to another, 

become inundated with messages without an efficient and 45 SUMMARY OF THE INVENTION 
effective means to manage them, especially with respect to 

news messages. The present invention satisfies the above-described needs 

Typically, news messages are formatted in a news con- by providing a system and method for managing conversa- 

versation threading structure or tree structure, which is a lion threads communicated in a client-server architecture, 

conversation threading scheme used by some electronic 50 Specifically, the present invention can generate conversation 

message systems. This tree structure generally consists of threading information for use in a MAPI format-sensitive 

complex message references with correspondingly unique application. Advantageously, the present invention effi- 

message identifiers. In this conversation threading scheme, ciently manages messages and optimizes communication 

related news messages are grouped together forming a between a client and server by using a database, stored at the 

conversation. A conversation will generally consist of a 55 client. The database maintains a central archive of message - 

conversation root and nested replies or reply messages. related information to support conversation threading of 

These nested replies or reply messages are commonly current and future messages downloaded from the server to 

referred to as children of the conversation root. Based on the me client. More particularly described, the present invention 

message references and identifiers, the tree structure is converts news conversation, threading to a MAPI format for 

arranged so that the conversation can retain its original 60 use in application programs which use a MAPI store, 

order. Specifically, the tree structure is arranged so that the The client-based database is used to support efficient 

conversation root is displayed first and reply messages are management of conversations so that conversation roots 

displayed thereafter in the order in which each is received. (root messages) and nested replies (reply messages) are 

The tree structure also accommodates reply messages that presented sequentially. Furthermore, the database includes 

stem from other reply messages and so forth. This form of 65 data fields corresponding to specific fields of a typical MAPI 

conversation threading allows messages to be retrieved from format. The database also includes data fields to assist in 

a server in a logical order. providing more efficient and timely operation of retrieving 
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and threading conversations from a local message store, 
such as a MAPI store. 

Toe present invention generally operates within the envi- 
ronment of a distributed computer system including a server 
and a client, where the client includes a local message store 5 
and a database. The present invention can manage conver- 
sation threads based on message-related information for a 
message having a message identifier and a references field, 
where the message-related information is stored in the 
database. During a client-server session, the message-related 3 q 
information corresponding to the message is retrieved from 
the server. Based on the message-related information, a 
determination is made as to whether the message has been 
previously downloaded from the server to the local message 
store located at the client. In response to determining that the a5 
message has not been previously downloaded from the 
server to the local message store, the message is downloaded 
from the server to the local message store, and data fields in 
the database are populated with the message-related infor- 
mation. A determination then is made as to whether the 2 o 
references field of the message is empty. In response to 
determining that the references field of the message is 
empty, indications are provided in the database that the 
message is a conversation root and that a conversation index 
has not been determined for the message. This entire process 2 s 
is performed for each remaining message on the server 
during this client-server session. Finally, the conversation 
index is generated for each downloaded message based on 
the conversation root. 

The message-related information generally comprises the 30 
message identifier for identifying the message, an article 
number for identifying the number of the article for the 
message, a title for identifying the title of the message, and 
a parent identifier for identifying the parent of the message. 
The message-related information also can include a posted 35 
or sent time for indicating a time and date that the message 
is posted to a database for news messages, preferably housed 
in a news server, such as an NNTP server. The data fields for 
the client-based database typically comprise a message 
identification field for the message identifier, an article 40 
number field for the article number, a title field for storing 
the title of the message, a parent identification field for 
storing the parent identifier for the message, and a posted 
time field for storing the time and date of the message. 

In another aspect, the present invention can generate a 45 
conversation index based on message -related information 
for a reply message. Preferably, the reply message is 
arranged in a news conversation threading structure and 
includes a message identifier and a reference, which includes 
a message identifier for a root message. The message-related 50 
information can be stored in a client-based database and 
includes the message identifier and a time and date for the 
root message and the reply message. Advantageously, the 
conversation index, which includes fields that are arranged 
in the MAPI format, supports conversation threading so that 55 
the root message and the reply message are grouped in a 
MAPI format for use in a MAPI format-sensitive applica- 
tion. To generate a conversation index from a reply message, 
a value, preferably "1", is placed in a first field of the 
conversation index. The database then is consulted to obtain 60 
the time and date for the root message, the message identifier 
for the root message, and the time and date for the reply 
message. The time and date of the root message is stored in 
a second field of the conversation index. A unique identifier 
is generated based on the message identifier of the root 65 
message and is stored in a third field of the conversation 
index. The difference between the time and date of the reply 
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message and the time and date of the root message is 
determined and stored in a fourth field of the conversation 
index. As a result, the conversation index represents the 
reply message in the MAPI format for use in the MAPI 
format -sensitive application. 

Advantageously, the present invention optimizes commu- 
nication with electronic mail servers by utilizing a client- 
based database. The present invention also accommodates 
news messages by converting the news messages to a 
conversation threading scheme that is compatible to MAPI 
format-sensitive applications. In addition, the present inven- 
tion effectively and efficiently keeps track of messages that 
are downloaded from a server to a client and maintains the 
message order of a threaded conversation. 

These and other objects, features, and advantages of the 
present invention may be more clearly understood and 
appreciated from a review of the following detailed descrip- 
tion of the disclosed embodiments and by reference to the 
appended drawings and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a client-server operating 
environment for an exemplary embodiment of the present 
invention. 

FIG. 2 is a block diagram of a client system for an 
exemplary embodiment of the present invention. 

FIG. 3 is a block diagram illustrating inter-operation of a 
client and server in accordance with an exemplary embodi- 
ment of the present invention. 

FIGS. 4a and 4b are diagrams illustrating a conversation 
threading scheme for news messages known as a tree 
structure in accordance with an exemplary embodiment of 
the present invention. 

FIGS. 4c and 4d are diagrams illustrating a generic 
conversion of the news messages in FIGS. 4a and 4b, 
respectively, to a MAPI formatted conversation index. 

FIG. 5 is a diagram of a MAPI-formatted conversation 
index generated from message-related information main- 
tained in a client-based database in accordance with an 
exemplary embodiment of the present invention. 

FIGS. 6a and 6b are diagrams illustrating a message 
manager database for archiving messages for conversation 
threading operations in accordance with an exemplary 
embodiment of the present invention. 

FIGS, la, lb, lc } 74 le, % 7& Ih, % and % collectively 
referred to as FIGS. la-lj, are diagrams illustrating a 
message manager database for archiving messages for con- 
versation threading operations in accordance with an exem- 
plary embodiment of the present invention. 

FIG. 8 is a flow diagram illustrating an exemplary method 
of operation utilizing a client-based database in accordance 
with an exemplary embodiment of the present invention. 

FIG. 9 is a flow diagram illustrating an exemplary process 
of downloading a message from the server to the client. 

FIGS. 10a and 10b, collectively referred to as FIG. 10, are 
flow diagrams illustrating an exemplary process of populat- 
ing data fields within a database. 

FIG. 11 is a flow diagram illustrating an exemplary 
process for creating a place holder in accordance with an 
exemplary embodiment of the present invention. 

FIG. 12 is a flow diagram illustrating an exemplary 
process for generating a conversation index based on 
message -related information in a database. 

DETAILED DESCRIPTION 

Generally, the present invention provides a system for 
managing messages communicated within a client-server 
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architecture, such as a distributed computing environment 
represented by a client and a server. Specifically, the present 
invention provides a system for managing conversation 
threads communicated in the client-server architecture. In an 
exemplary embodiment, the invention is incorporated into 
the "MICROSOFT OUTLOOK '98" application program, 
which is produced and distributed by Microsoft Corporation 
of Redmond, Wash. The "MICROSOFT OUTLOOK '98" 
application program can manage e-mail, calendars, contacts, 
tasks and to-do lists, and documents or files on a hard drive. 
The present invention, preferably implemented as a message 
manager program module ("message manager"), uses a 
database, stored at the client, to maintain a central archive of 
message-related information to support conversation thread- 
ing of current and future messages downloaded from the 
server to the client. The present invention also converts news 
messages in a news conversation threading structure to a 
MAPI format for use in application programs which use a 
MAPI store. 

Referring now to the drawings, in which like numerals 
represent like elements throughout the several figures, 
aspects of the present invention and an exemplary operating 
environment will be described. 

EXEMPLARY OPERATING ENVIRONMENT 

The following discussion is intended to provide a general 
description of a suitable computing environment in which 
the invention may be implemented. While the invention will 
be described in the general context of an application pro- 
gram that runs on an operating system in conjunction with 
a personal computer and in connection with a server, those 
skilled in the art will recognize that the invention also may 
be implemented in combination with other program mod- 
ules. Generally, program modules include routines, operat- 
ing systems, application programs, components, data 
structures, etc. that perform particular tasks or implement 
particular abstract data types. Moreover, those skilled in the 
art will appreciate that the invention may be practiced with 
other computer system configurations, including hand-held 
devices, multiprocessor systems, microprocessor-based or 
programmable consumer electronics, minicomputers, main- 
frame computers, and the like. 

The invention may also be practiced in distributed com- 
puting environments where tasks are performed by remote 
processing devices that are linked through a communica- 
tions network. In a distributed computing environment, 
program modules may be located in both local and remote 
memory storage devices. Execution of the program modules 
may occur locally in a stand-alone manner or remotely in a 
client/server manner. Examples of such distributed comput- 
ing environments include local area networks of an office, 
enterprise -wide computer networks, and the Internet. 

The Internet, which is a global web of interconnected 
computers and computer networks, integrates local area 
networks (LANs) located in various entities, such as 
businesses, libraries, federal agencies, institutes of learning, 
and research organizations into a single communication 
network. The Internet uses a common communication pro- 
tocol suite, known as a Transmission Control Protocol/ 
Internet Protocol (TCP/IP), which was specifically designed 
for the interconnection of different computer systems. Inter- 
nal and external networks are linked by routers that route 
data packets from a sending network to another router or a 
receiving network. Gateways handle data transfer and con- 
version of messages from a sending network to the protocols 
used by a receiving network. Typically, gateways refer to 
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devices that translate between applications. For example, 
e-mail gateways translate messages from one vendor's mes- 
saging program to another vendor's messaging program so 
that users with different e-mail programs can share messages 
over a network. 

The Internet uses a message standard, known as a Simple 
Mail Transfer Protocol (SMTP), which works in conjunction 
with a user's e-mail program and defines the control mes- 
sages used by two computers to exchange e-mail messages. 
Such controls include verification of proper connection, 
identification of sender, negotiation of transmission 
parameters, and message transmission. SMTP is responsible 
for 1) sending mail created by a local* user to another 
computer and 2) receiving mail from other computers on the 
network and transferring it to the local user's e-mail pro- 
gram. 

Typically, the computers connected to a wide area net- 
work such as the Internet are identified as either servers or 
clients. A server is a computer that stores files that are 
available to the other computers connected to the network. 
For example, an e-mail server manages message traffic and 
mail boxes for users, in addition to translation facilities or 
gateways that allow message exchange between different 
types of e-mail programs. A client is a computer connected 
to the network that accesses shared resources provided by a 
server. To obtain information from a server, a client makes 
a request for a file or information located on the server using 
a specified protocol. Upon reception of a properly formatted 
request, the server downloads the file or information to a 
local message store located at the client. 

FIG. 1 illustrates a typical client-server environment 10 in 
which an exemplary embodiment of the present invention 
operates. A computer system or client 1, such as a conven- 
tional personal computer or any device operable to commu- 
nicate over a network, is connected to an Internet server 
computer 3 ("server"). The server 3 is generally provided by 
an Internet service provider (ISP), which provides Internet 
access for a typical Internet user. The server 3 is connected 
to a distributed computer network 5, such as the Internet, and 
enables the client 1 to communicate via the distributed 
computer network 5. 

The client 1 communicates via the combination of the 
server 3 and the distributed computer network 5 to a server 
7, such as a communication or an e-mail server. In an 
exemplary embodiment, servers 3 and 7 support e-mail 
services, contain a message store for holding messages until 
delivery, and contain a translation facility or gateway for 
allowing users having different e-mail programs to exchange 
mail. The server 7 is connected to an internal network 9 and 
enables the client 1 to communicate with the clients 11a, 
lib, and 11c via the internal network 9. 

The clients Ha, lib, and 11c are not only able to respond 
to a communication from the client 1, but are also able to 
initiate communication with the client 1. The clients Ha, 
lib, and 11c can send information via the internal network 
9 to the server 7. The server 7, in turn, forwards the 
information to the client 1 via the distributed computer 
network 5. The information is retrieved by the server 3 and 
can be forwarded to the client 1, when requested by the 
client 1. 

With reference to FIG. 2, an exemplary system for imple- 
menting the invention includes a conventional personal 
computer 20, which serves as a client. The client 20 may 
represent any or all of the clients 1, 11a, Hb, and 11c 
illustrated in FIG. 1. The client 20 includes a processing unit 
21, a system memory 22, and a system bus 23 that couples 
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the system memory to the processing unit 21. The system 
memory 22 includes read only memory (ROM) 24 and 
random access memory (RAM) 25. A basic input/output 
system 26 (BIOS), containing the basic routines that help to 
transfer information between elements within the client 20, 
such as during START-up, is stored in ROM 24. The client 
20 further includes a hard disk drive 27, a magnetic disk 
drive 28, e.g., to read from or write to a removable disk 29, 
and an optical disk drive 30, e.g., for reading a CD -ROM 
disk 31 or to read from or write to other optical media. The 
hard disk drive 27, magnetic disk drive 28, and optical disk 
drive 30 are connected to the system bus 23 by a hard disk 
drive interface 32, a magnetic disk drive interface 33, and an 
optical drive interface 34, respectively. The drives and their 
associated computer-readable media provide nonvolatile 
storage for the client 20. Although the description of 
computer-readable media above refers to a hard disk, a 
removable magnetic disk and a CD-ROM disk, it should be 
appreciated by those skilled in the art that other types of 
media which are readable by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks, Bernoulli 
cartridges, and the like, may also be used in the exemplary 
operating environment. 

A number of program modules may be stored in the drives 
and RAM 25, including an operating system 35, one or more 
application programs, such as an e-mail program module 36, 
other program modules, such as a message manager pro- 
gram module 37, a local message store 38, and a database 39 
for supporting e-mail applications. A user may enter com- 
mands and information into the client 20 through a keyboard 
40 and pointing device, such as a mouse 42. Other input 
devices (not shown) may include a pen, touch-operated 
device, microphone, joystick, game pad, satellite dish, 
scanner, or the like. These and other input devices are often 
connected to the processing unit 21 through a serial port 
interface 46 that is coupled to the system bus, but may be 
connected by other interfaces, such as a game port or a 
universal serial bus (USB). A monitor 47 or other type of 
display device is also connected to the system bus 23 via an 
interface, such as a video adapter 48. In addition to the 
monitor, personal computers typically include other periph- 
eral output devices (not shown), such as speakers or printers. 

The client 20 operates typically in a networked environ- 
ment using logical connections to one or more remote 
computers, such as a remote computer 49. The remote 
computer 49 may be an e-mail server (which includes one or 
more message stores), as described above in connection with 
FIG. 1, a file server (which includes one or more file stores), 
a router, a peer device or other common network node, and 
typically includes many or all of the elements described 
relative to the client 20, although only a memory storage 
device 50 has been illustrated in FIG. 2. The logical con- 
nections depicted in FIG. 2 include a local area network 
(LAN) 51 and a wide area network (WAN) 52. Such 
networking environments are commonplace in offices, 
enterprise -wide computer networks, intranets and the Inter- 
net. 

When used in a LAN networking environment, the client 
20 is connected to the LAN 51 through a network interface 
53. When used in a WAN networking environment, the 
client 20 typically includes a modem 54 or other means for 
establishing communications over the WAN 52, such as the 
Internet. The modem 54, which may be internal or external, 
is connected to the system bus 23 via the serial port interface 
46. In a networked environment, program modules depicted 
relative to the client 20, or portions thereof, may be stored 
in the remote memory storage device. It will be appreciated 
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that the network connections shown are exemplary and other 
means of establishing a communications link between the 
computers may be used. 

With continuing reference to FIGS. 1 and 2, FIG. 3 is a 

5 diagram illustrating inter-operation of a client and server in 
accordance with an exemplary embodiment of the present 
invention. This exemplary embodiment is embodied in the 
"MICROSOFT OUTLOOK '98" application program, 
which is published by Microsoft Corporation of Redmond, 

10 Wash. The program helps users communicate through 
e-mail, phone support and group scheduling capabilities, and 
allows users to create and view information using a consis- 
tent interface. The "MICROSOFT OUTLOOK '98" pro- 
gram supports an exemplary program module, namely a 
message manager program module 37, for managing mes- 

15 sages. The "MICROSOFT OUTLOOK '98" program also 
supports various Internet protocols, including, but not lim- 
ited to protocols known in the art such as Internet Message 
Access Protocol (IMAP), version 3.0 of Post Office Protocol 
(POP3), Simple Mail Transfer Protocol (SMTP), Multipur- 

20 pose Internet Mail Extensions (MIME), and Hyper Text 
Markup Language (HTML), and Network News Transfer 
Protocol (NNTP). 

In FIG. 3, a remote computer 49 operates as a server and 
generally includes an e-mail server application 110, a local 

25 store 115, and a client manager control 120. In an exemplary 
embodiment, the remote computer 49, also described as a 
server, is a POP3 mail server, but it will be appreciated that 
the present invention is not limited to this type server. In the 
exemplary embodiment, the client 20 includes a local mes- 

30 sage store 38, a database 39, an e-mail program module 36, 
and a message manager program module 37 for facilitating 
message management and operation of the database 39. 

With respect to the exemplary embodiment, the client 20 
provides two modes of operation in connection with the 

35 server 49. These modes are a default mode and a "leave on 
server" mode. In the default mode, the client 20 sends a 
delete command to the server 49 to delete a message from 
the server 49 after the message has been downloaded to the 
client 20. In the "leave on server" mode, the client does not 

40 send a delete command to the server 49 after the message 
has been downloaded to the client 20, thereby allowing the 
message to remain on the server 49 although the message 
has been downloaded. The mode of operation generally is 
selected based on user-preference. Advantageously, an 

45 exemplary embodiment of the present invention optimizes 
the management of messages when the client 20 is in the 
"leave on server" mode, which is the preferred mode of 
operation for purposes of this discussion. 
The server 49 houses e-mail messages from clients in the 

50 local store 115 while awaiting transmission to an appropriate 
destination. The e-mail server application 110 forwards 
messages over the WAN 52 from a sender client (not shown) 
to the client 20, upon request by the client 20. The client 
manager control 120 is a program used to set up computer 

55 systems, such as clients 1, 11a, lib, He (FIG. 1), and 20 
(FIG. 2) on the network. The client manager control 120 can 
also specify the addresses of the computer systems located 
on the network. In addition, the client manager control 120 
typically facilitates the management of incoming and out- 

60 going messages on the server. When a request for a message 
is made by the client 20 to the server 49, the e-mail server 
application 110 on the server 49 responds by retrieving the 
message from the local store 115 on the server 49 and by 
transmitting the message over the WAN 52 to the client 20. 

65 The message is then downloaded into the local message 
store 38 located at the client 20. The local message store 38 
houses all downloaded messages from the server 49. 
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There are essentially two types of e-mail messages that 
are usually downloaded from the server 49 to the client 20. 
These message types are news messages and general mail 
messages. Although the present invention efficiently man- 
ages both types of messages, this embodiment of the present 
invention specifically addresses managing news messages. 

News messages generally include items such as articles, 
bulletins, information, and data that are distributed to Inter- 
net users or subscribers through direct mailing on the 
Internet and through the USENET news system. The 
USENET news system provides a central repository of news 
messages in a database (not shown) and allows a subscriber 
to select those items he or she desires to read. The database 
(not shown) preferably is housed in a news server (not 
shown), such as an NNTP server. NNTP specifies the 
protocol for the distribution, inquiry, retrieval, and posting 
of news messages. NNTP is designed so that news messages 
can be stored at a central database at one host and can be 
accessed by subscribers from remote locations. 

An application program, such as the "MICROSOFT 
OUTLOOK '98" program, provides a user-friendly interface 
for facilitating interaction with the database (not shown) for 
the news messages. The server 49 serves as an interface 
between the database for the news messages and the appli- 
cation program. Unfortunately, due to the conversation 
threading scheme for news messages, an application pro- 
gram that is MAPI format-based cannot handle downloading 
these news messages and maintaining their order. 
Consequently, an exemplary embodiment of the present 
invention provides the benefit of converting the conversation 
threading scheme of news messages to a conversation 
threading scheme that can be managed by a MAPI format- 
sensitive application. 

This exemplary embodiment efficiently manages news 
messages and optimizes communication between a client 
and server by using a database, stored at the client. The 
database maintains a central archive of message-related 
information to support conversation threading of news mes- 
sages downloaded from the server to the client. The database 
includes data fields corresponding to specific fields of a 
typical MAPI format. The database also includes data fields 
to assist in providing more efficient and timely operations of 
retrieving and threading conversations from a local message 
store, such as a MAPI store. 

With continuing reference to FIGS. 1-3, FIGS. 4a and 4b 
illustrate a conversation threading scheme for news mes- 
sages known as a tree structure. The tree structure is a 
common format for news messages. For purposes of this 
discussion, news messages are referred to herein as simply 
"messages". FIGS. 4a and 4b are used as examples of a 
simple case and a complex case, respectively, and are 
referred to throughout this discussion to demonstrate opera- 
tion of an exemplary embodiment of the present invention in 
connection with FIGS. 6a and 6b and FIGS, la-lj. 

Each message usually includes a message identifier or ID 
and a references field. The message ID is a identification 
string, which typically is derived from a header of the 
message itself, that uniquely identifies the message. For 
purposes of this discussion, a message ID is represented as 
a single character for simplicity. The references field iden- 
tifies other correspondence which the message references. 
Specifically, the references field lists message IDs of any 
messages prompting the submission of the message. The 
purpose of the references field is to allow messages to be 
grouped into conversations by a program module, such as an 
application program or a browser. A message that does not 
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have any references in its references field is a conversation 
root or root message. As used herein, the terms "conversa- 
tion root" and "root message" are interchangeable and 
represent an original message having no references. A mes- 

5 sage that has references in its references field may be 
referred to as a reply message. The message may also 
include a message title, an article number, and other items 
that are described in connection with FIGS. 5-12. 
In FIG. 4a, a simple tree structure is illustrated for a group 

10 of messages associated with article number 100. In row 100, 
Message 1 has a message ID "A" and no references in its 
references field. Moreover, Message 1 is a conversation root. 
In row 102, Message 2 has a message ID "B" and a 
references field consisting of <A>. In row 104, Message 3 

15 has a message ID "C" and a references field consisting of 
<A><B>. In row 106, Message 4 has a message ID "D" and 
a references field consisting of <A>. 

Assuming that each message ID represents a message, the 
messages are typically linked in a tree-like format based on 

20 the contents of the references fields, as illustrated in FIG. 4a. 
Specifically, Message 1 is directly linked to Message 2 and 
Message 4, and Message 2 is directly linked to Message 3. 
In FIG. 4bj a more complex tree structure is illustrated for 

25 a group of messages associated with article number 200. In 
row 110, Message 1 has a message ID "A" and no references 
in its references field. Moreover, Message 1 is a conversa- 
tion root. In row 112, Message 2 has a message ID "B" and 
a references field consisting of <A>. In row 114, Message 3 

3Q has a message ID "C" and a references field consisting of 
<AxB>. In row 116, Message 4 has a message ID "D" and 
a references field consisting of <A>. In row 118, Message 5 
has a message ID "E" and a references field consisting of 
<A><D>. In row 120, Message 6 has a message ID "F" and 

35 a references field consisting of <A><D><E>. In row 122, 
Message 7 has a message ID "G" and a references field 
consisting of <DxExF>. In row 124, Message 8 has a 
message ID "H" and a references field consisting of 
<A><DxE>. 

40 As illustrated in FIG. 4b, Message 1 is directly linked to 
Message 2 and 4; Message 2 is directly linked to Message 
3; Message 4 is directly linked to Message 5; Message 5 is 
directly linked to Message 6 and Message 8; and Message 6 
is directly linked to Message 7. 

45 Advantageously, the exemplary embodiment converts the 
tree structures illustrated in FIGS. 4a and 4b into a MAPI 
format conversation index shown in FIGS. 4c and 4d, where 
FIG. 4c corresponds to FIG. 4a and where FIG. 4d corre- 
sponds to FIG. 4b. FIGS. 4c and 4d, used as examples of a 

50 simple case and a complex case, respectively, are referred to 
throughout this discussion to demonstrate operation of the 
exemplary embodiment in connection with FIGS. 6a and 6b 
and FIGS, la-lj. 

With continuing reference to FIGS. 4c and 4d and turning 

55 to FIG. 5, a diagram illustrating a conversation index in 
accordance with an exemplary embodiment of the present 
invention is described. A conversation index 200, also 
known as a PR_Conversation_Index, is a conversation 
threading format used in a MAPI store. If the message is a 

60 reply message, the conversation index 200 typically includes 
a preamble 201 and a child of conservation 202. However, 
if the message is a conversation root, the conversation index 
200 only includes the preamble 201. Once a preamble is 
generated for a conversation root, a conversation index can 

65 be generated for all reply messages having the same con- 
versation root. The preamble of the conversation index 200 
is common to all reply messages having the same conver- 
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sation root, as shown in FIGS. 4c and 4d. Advantageously, receiving, and forwarding messages, while the message 

an exemplary embodiment of the present invention stores manager program module 37 manages messages during 

message-related information for generating a conversation download and conversation threading operations utilizing 

index in the client-based database 39. the database 39. 

The conversation index 200 contains fields 205, 210, 215, 5 in prior systems, messages are typically rethreaded each 
and 220. In MAPI format, the size of the fields are as time messages are downloaded. An exemplary embodiment 
follows: the first field 205 is one byte; the second field 210 of the present invention solves this problem by utilizing the 
is five bytes; the third field is sixteen bytes; and a fourth field database to keep track of downloaded messages and Con- 
or reply message field 220 is five bytes. It is understood by versation threading information. The use of the database 39 
those skilled in the art that a conversation index can have io is described in greater detail in connection with FIGS. 6a 
more than one reply message field, as illustrated in FIGS. 4c and 6b, collectively described as FIG. 6, and FIGS. 7a-7j, 
and 4d. collectively described as FIG. 7. 

Fields 205, 210, and 215 make up the preamble. With continuing reference to FIGS. 1-5, FIGS. 6a and 6b 

Preferably, a value of "1" is placed in the first field 205. The and FIGS, la-lj illustrate a client-based database for 

second field 210 is populated with the sent time of the 35 archiving messages relating to conversation threading in 

conversation root. The sent time is the time and date that a accordance with an exemplary embodiment of the present 

message is sent to a database for news messages, preferably . invention. 

housed in a news server. The third field 215 is populated The database 39 can include multiple data fields, orga- 
with a unique identifier or ID for the conversation root. The n ized within an array structure, for maintaining message- 
unique ID is generated from the message ID of the root 20 related information. To support download and conversation 
message using a "hashing" process, which converts the threading operations, typical data fields of the database 
arbitrary length message ID to a fixed length unique ID. include: an entry identification (EID) 300, an article number 
Finally, if a message is a reply message, the message has 305, a title 310, a message identification (message ID) 315, 
at least one reply message field 220. The reply message field a parent identification (parent ID) 320, a posted time 325, a 
220 is populated with a difference "delta" equal to the 25 "root" flag 330, a "dirty" flag 335, and a "place holder" flag 
difference between the sent time of the reply message and 340. 

the sent time of the conversation root. Operation of the database 39 in connection with the 
Each child of conversation 202 represents the reply mes- message manager program module 37 (FIG. 3) is presented 
sage and each reference, except for the reference for the root 3Q by way of two representative examples. The first example is 
message, in the references field of the reply message. For a simple case in which a root message and reply messages 
example, turning briefly to FIG. 4d, the conversation index are downloaded during a single client -server session. This 
124a for Message 8 has a preamble derived from a root example is illustrated in FIGS. 6a and 6b with continuing 
message (message ID "A") and three children of the con- reference to FIGS. 3, 4a, and 4c. In this example, a con- 
versation derived from each reference, message ID "D" and 35 nection is made between a client 20 (FIG. 3) and server 49 
message ID "E", as well as the reply message itself, message (FIG. 3). A user desires to check her download news 
ID "H". messages and is typically prompted by the e-mail program 
For a place holder that is a conversation root, a preamble module 36 (FIG. 3) to enter a password for access to the 
is generated by using a message ID from the references field messages. 

of a different message. In addition, the sent time for a place ^ The server 49 contains four messages in its local store 

holder is an arbitrary date and time in the past. Once the 115. These messages are entitled Message 1, Message 2, 

conversation index for a place holder conversation root is Message 3, and Message 4, as shown in FIG. 4a. Message 

generated, a conversation index for a related message can 1 has no reference in its references field and has a message 

also be generated. Place holders will be described in greater ID "A". Message 2 has a references field consisting of 

detail in connection with FIGS. 6-11. 45 <A>and has a message ID "B". Message 3 has a references 

In view of the foregoing, the present invention provides field consisting of <A><B>and has a message ID "C". 

the benefit of threading conversations without complex Message 4 has a references field <A>and has a message ID 

referencing schemes like a tree structure. Furthermore, the "D". 

present invention provides an efficient process for convert- Referring to FIG. 6a, the client 20 transmits a command 
ing a tree structure to a MAPI format for use in a MAPI 50 to retrieve a message ID for a message. The server responds 
store. Moreover, by converting a message to the MAPI by transmitting to the client a message ID "A". As previ- 
format, missing messages do not ruin the message order, as ously mentioned in connection with FIG. 4a, the message 
can occur in systems that use a tree structure. Additional having a message ID "A" is a conversation root and, 
features and advantages of the present invention are consequently, the message has no reference in its references 
described in connection with the download operation and 55 field. The client checks the database 39 to determine whether 
use of the database for storing message-related information there are any message entries having the message ID "A". In 
for managing conversation threads. this example, there are no message entries having this 
During the download operation, data fields are populated message ID. As a result, the associated message is down- 
within the database 39 with message-related information for loaded in the local message store 38, which in this case is a 
conversation threading in association with the downloaded 60 MAPI store. 

message. The information includes an article number for During download operations, data fields 300, 305, 310, 

identifying the article, a message identifier for uniquely 315, 320, 325, 330, 335, and 340 within the database 39 are 

identifying the message, a message title for identifying the populated with message-related information associated with 

title of the message, and other message-related information the message. Specifically, an entry identifier is populated in 

that will be described in greater detail herein below with 65 an EID field 300, an article number is populated in an article 

respect to FIGS. 6-11. The e-mail program module 36 number field 305, a title is populated in a title field 310, the 

provides facilities for creating, addressing, sending, message ID is populated in a message ID field 315, a parent 
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ID is populated in a parent ID field 320, and a time and date the database 39 are populated with message-related infor- 

or sent time are populated in a posted time field 325. In this mation associated with the message. The message-related 

representative example, the message-related information for information for a message entry associated with the message 

a message entry associated with the message having a having a message ID of "B" includes: EID "2", article 

message ID of "A" includes: EID "1", article number "100", 5 number "100", title "Message 2", message ID "B", parent ID 

title "Message 1", message ID "A", and posted time "Jan. 1, "A", and posted time "Jan. 1, 1998 08:01:00". The "root" 

1998 08:00:00". As previously mentioned, the message is a flag is set to a false state in the "root" flag field 330 because 

conversation root. Therefore, the message does not have a Message 2 is not a conversation root and depends from 

parent ID, as shown in FIG. 6a, and a "root" flag is set to a Message 1, as shown in FIG. 4a. Also, a "dirty" flag for 

true state in the "root" flag field 330. ao Message 2 is set to a true state in the "dirty" flag field 335. 

The "root" flag exists in two states, namely a true state and In addition, a "place holder" flag is set to a false state in the 

a false state. The true state serves as an indicator that the "place holder" flag field 340. 

message is a conversation root. The false stale serves as an It will be appreciated by those skilled in the art that in a 

indicator that the message is not a conversation root. The tree structure format, the parent ID is typically the last 

message manager 37 keeps track of which messages are root 35 referenced message ID in the references field of the mes- 

messages for generating conversation indices. Once a con- sage. In addition, the parent ID is preferably an internal 

versation index is generated for a root message, reply pointer for pointing to the last referenced message ID. 

messages that depend from the root message can be orga- However, for purposes of this discussion, a single character 

nized easily and efficiently. is used to represent the parent ID for simplicity. 

In response to downloading the message to the local 20 Next, Message 3 is downloaded and the data fields 300, 

message store 38, a "dirty" flag is set to a true state in the 305, 310, 315, 320, 325, 330, 335, and 340 within the 

"dirty" flag field 335. The "dirty" flag also exists in a true database 39 are populated with message-related information 

state and a false state. The true state of the "dirty" flag is associated with the message. The message -related informa- 

indicative of a message that does not have a conversation tion for a message entry associated with the message having 

index set in the local message store. The true state of the 25 a message ID of "C" includes: EID "3", article number 

"dirty" flag is also indicative of the message being "dirtied" "100", title "Message 3", message ID "C", parent ID "B", 

because a conversation index of another message from and posted time "Jan. 1, 1998 08:02:00". The "root" flag is 

which the message depends has not been set or has become set to a false state in the "root" flag field 330 because 

"dirtied". The false state of the "dirty" flag serves as an Message 3 is not a conversation root and depends from 

indicator that a conversation index has been generated for 30 Message 2, as shown in FIG, 4a. Also, a "dirty" flag for 

the message. Message 3 is set to a true state in the "dirty** flag field 335, 

Further in response to downloading the message, a "place and a "P lace holder" flag is set to a false state in the "place 

holder" flag is set to a false state in the "place holder" flag holder" flag field 340. 

field 340. A place holder also exists in a true state and a false 35 Referring again to FIG. 6a, Message 4 is downloaded and 

state. The true state serves as an indicator that the message the data fields 300, 305, 310, 315, 320, 325, 330, 335, and 

is a place holder. The false state serves as an indicator that 340 within the database 39 are populated with message- 

the message is not a place holder. Specifically, a place holder related information associated with the message. The 

is a message entry for a message that has not yet been message-related information for a message entry associated 

downloaded, which is referred to herein as a "non- ^ with the message having a message ID "D" includes: EID 

downloaded message". The message manager is aware of a "4", article number "100", title "Message 4", message ID 

message's existence if a message ID for the non- "D", parent ID "A", and posted time "Jan. 1, 1998 

downloaded message is referenced in a references field of an 08:03:00". The "root" flag is set to a false state in the "root" 

already downloaded message. Consequently, the message flag field 330 because Message 4 is not a conversation root 

manager sets up a place holder to reserve a place for the 45 and depends from Message 1, as shown in FIG. 4a. Also, a 

non-downloaded message in the database. Any information "dirty** flag for Message 4 is set to a true state in the "dirty*' 

about the non-downloaded message that can be gleaned flag field 335, and a "place holder*' flag is set to a false state 

from the already downloaded message is stored in appro- in the "place holder" flag field 340. 

priate data fields in the database as an incomplete message After all of the messages have been downloaded and the 

entry. If or when the non-downloaded message is down- 5Q data fields have been populated, the message manager 37 

loaded to the client 20, the remaining data fields for the generates a conversation index for each message entry 

incomplete message entry are populated with the appropriate having a "dirty" flag set to a true state. Generation of a 

information. In this example, the place holder is set to a false conversation index is described in greater detail below in 

state because the message has been downloaded and the connection with FIG. 12. The conversation index for a 

message entry for the message is complete. 55 conversation root is generated first because other messages 

Referring to FIG. 6a, once Message 1 has been down- may depend on the conversation root and share a common 

loaded and the appropriate data fields have been populated, preamble, which is based on the conversation index of the 

the message manager 37 determines whether there are any conversation root. For example, referring back to FIG. 4a, 

more messages to be downloaded from the server 49 to the Message 2 102, Message 3 104, and Message 4 106, all 

client 20. In this example, there are three messages remain- 60 depend from Message 1 100. Hence, referring to FIG. 4c, the 

ing on the server 49. The next message ID is retrieved and preamble for each message consists of information derived 

the downloading process is repeated, where a determination from Message 1 having a message ID "A", 

is made as to whether the message ID matches any message Referring again to FIG. 6a, in this example, the conver- 

IDs in the database 39. The entire process is repeated for sation root is Message 1 based on the fact that the "root" flag 

each of the remaining messages on the server. 65 is set to a true state in the database 39. As a result, the 

In this example, Message 2 is downloaded and the data conversation index for Message 1 is generated in a MAPI 

fields 300, 305, 310, 315, 320, 325, 330, 335, and 340 within conversation threading scheme similar to the one shown for 
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Message 1 100a in FIG. 4c and previously -described in 
connection with FIG. 5. After this conversation index is 
generated, the conversation indices for the reply messages, 
namely Message 2, Message 3, and Message 4, are gener- 
ated. The reply messages maintain a conversation threading 
scheme similar to the structures 102a, 104a, and 106a 
illustrated in FIG. 4c. 

After all of the conversation indices are generated, the 
conversation indices are stored in the local message store 38 
in connection with the appropriate messages. Also, the 
"dirty" flags then are set to a false state to indicate that the 
conversation indices are set for the messages, as shown in 
FIG. 6b. The client-server session is completed and discon- 
tinued. 

Advantageously, an exemplary embodiment of the present 
invention provides means for efficiently managing threaded 
conversations. A database is consulted during download 
operations to determine if message entries exist for down- 
loaded messages, and if not, message entries are created for 
those messages that are not already entered in the database. 
The database is used to create and manage threaded con- 
versations. Moreover, if any data changes with respect to the 
messages, such as a message becoming dirtied, the database 
is updated to reflect those changes so that information in the 
MAPI store remains in synchronization with server infor- 
mation. A conversation index is created for each message 
entry so that messages like those provided in news groups 
can operate in a MAPI format and be used in a software 
environment, like that of the "MICROSOFT OUTLOOK 
'98" program. Advantageously, the conversation index is 
updated only when necessary, thereby minimizing the 
amount of changes made in the MAPI store. 

These features and advantages can be further appreciated 
by way of a second representative example. The second 
example is a more complex case in which a root message 
and reply messages are downloaded during several client- 
server sessions. This example is illustrated in FIGS. 7a-7j 
with continuing reference to FIGS. 3, 46, and 4d. In this 
example, a connection is made between a client 20 (FIG. 3) 
and server 49 (FIG. 3). A user desires to check her download 
news messages and is typically prompted by the e-mail 
program module 36 (FIG. 3) to enter a password for access 
to the messages. 

In this example, assume there are four client-server ses- 
sions. In a first client-server session, there is only one 
message, namely Message 7, on the server 49 to be down- 
loaded to the client 20. As shown in FIG. 4b, Message 7 has 
a references field consisting of <D><E><F>and has a mes- 
sage ID "G". In a second client-server session, there is only 
one message, namely Message 8, to be downloaded from the 
server 49 to the client 20, In FIG. 4b, Message 8 has a 
references field consisting of <A><D><E>and has a mes- 
sage ID "H". In a third client-server session, there are three 
messages to be downloaded. Referring still to FIG. 4b, these 
messages include: Message 1 having no references in its 
reference field and having a message ID "A"; Message 4 
having a references field consisting of <A>and having a 
message ID "D"; and Message 5 having a references field 
consisting of <AxD>and having a message ID "E". Finally, 
in a fourth client-server session, there is only one message 
to be downloaded, namely Message 6, which has a refer- 
ences field consisting of <A, D, E>and has a message ID 
"F". 

Turning to FIG. 7a, in the first client-server session, the 
client 20 transmits a command to retrieve a message ID for 
a message. The server responds by transmitting to the client 
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a message ID "G". The client checks the database 39 to 
determine whether there are any message entries having the 
message ID "G". In this example, there are no message 
entries having this message ID. As a result, the associated 

5 message, in this case Message 7, is downloaded in the local 
message store 38. 

In response to downloading the message, the data fields 
300, 305, 310, 315, 320, 325, 330, 335, and 340 within the 
database 39 are populated with message-related information 

1(J associated with the Message 7. This information includes: 
EID "1", article number "200", title "Message 7", message 
ID "G'\ parent ID "F", and posted time "Jan. 2, 1998 
08:00:00". As previously mentioned in connection with 
FIGS. 6a and 6b, the parent ID is typically the last refer- 
enced message ID in the references field of the message. In 

15 this case, Message 7 has a references field consisting of 
<DxE><F>and the last referenced message ID is "F". 
Hence, the message having a message ID "F" is the parent 
ID for Message 7. The "root" flag is set to a false state in the 
"root" flag field 330 because Message 7 is not a conversation 

20 root and depends from Message 6, as shown in FIG. 4a. 
Also, a "dirty" flag for Message 7 is set to a true state in the 
"dirty" flag field 335. In addition, a "place holder" flag is set 
to a false state in the "place holder" flag field 340. 

Due to the fact that Message 7 has references, a determi- 

25 nation is made as to whether each referenced message ID 
matches a message ID in the message ID field 315 in the 
database. The determination is made by checking the last 
referenced message ID first and proceeding from right to left 
in the references field for the message. If there is a match, 

30 the message having the referenced message ID has already 
been downloaded. On the other hand, if there is not a match, 
the associated message has not been downloaded. Hence, a 
place holder is created for the referenced message ID. Any 
information about the non-downloaded message that can be 

35 obtained from the already downloaded message is stored in 
appropriate data fields in the database as an incomplete 
message entry. 

In this example, the last referenced message ID is "F" for 
Message 7. This message ID is not already found in the 

40 database 39. Therefore, a place holder is created for the 
non-downloaded message. Based on the message-related 
information for Message 7 in the database, the place holder 
includes: EID "2", Article number "200", message ID "F", 
and parent ID "E", The parent ID is preferably determined 

45 by checking the next referenced message ID, from right to 
left, in the references field of Message 7. This method of 
determining the parent ID is generally reliable because there 
is a presumption that all of the messages are referenced in 
the references field and that the message IDs are presented 

50 in order. The "root" flag is set to a false state because the 
message has a parent ID. The "dirty" flag is set to a true 
state, and the "place holder" flag is set to a true state. This 
procedure is executed for each referenced message ID in the 
references field of the message. 

55 In FIG. 7a, a place holder is created for message ID "E". 
The place holder includes: EID "3", Article number "200", 
message ID "E", and parent ID "D". The "root" flag is set 
to a false state; the "dirty" flag is set to a true state; and the 
"place holder" flag is set to a true state. In addition, a place 

60 holder is created for message ID "D". The place holder 
includes: EID "4", Article number "200", message ID "D", 
and no parent ID. The message manager determines that the 
message having message ID "D" is a conversation root 
because there are no more referenced messages. As a result, 

65 the "root" flag is set to a true state. In addition, the "dirty" 
flag is set to a true state, and the "place holder" flag is set to 
a true state. 
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After the message has been downloaded and the message- to a true state. In addition, the "dirty" flag is set to a true 

related information is populated in the database 39, the state, and the "place holder" flag is set to a true state. 

message manager 37 generates a conversation index for each M noted ^ lhe references field for Message 8, the 

message entry having a "dirty" flag set to a true state. The referenced message ID « D » depends from the re f er enced 

conversation root preferably is generated first. In this 5 m e ID „ A „ Based 0Q this information> lhe message 

example, the conversation root is the message having the „ , , . t . ?L 

( m». , i . „ „, a . & tl _ j |^ manager determines that the message having the message ID 

message ID D as noted by the root flag in the database <tr ^» • . . a , t , . , , 

39. The conversation index 116* (FIG. 4d ) is generated for f 15 DOt a ™™™ tl0D ft * re ^V he / ace ^ldcr 

the message having the message ID "D". One? the conver- ™*?P 10 ° ^! ^ S f c ^ cal J* f he P arcnl ID 

sation index for the conversation root is generated, the in ^"20 for ^message ID "D is updated to indicate message 

message manager 37 methodically determines which con- 10 " , f ^ PareDt ^'J? ^ ^ * M 33 ° 15 

versation index to generate next based on a message entry's u P dated b ? f chaD S m S ^ ' ™ l J? 1 ** 0 ™ a true state t0 a 

dependency on the conversation root. In other words, the f^lse state for message ID D . Finally all message entries 

message manager 37 preferably checks the parent ID field ^ at (( d A e r nd from th f ™isation root having the message 

320 to determine which message entries directly depend „ "> m u P dated b * cha ?S 1D S the i a § s from a 

from the conversation root and generates the conversation 15 faIse u sta ^ t0 » l ™ e state * as shown m f lG ' 7c u ^ { ™ state 

index for those message entries. Based on those message of the as aD mdlcaU ? r that either the 

entries, the message manager 37 checks the parent ID field conversation index has not been generated or the conversa- 

320 for the next message entries and generates the conver- tl0n mdex must be u P dated * 

sation index for the next message entries. This process 2Q Next » tne message manager 37 generates a conversation 
continues until all conversation indices have been generated mdex for eacn message entry having a "dirty" flag set to a 
for message entries having a "dirty" flag set to a true state. true state - 1° this example, the conversation root is the 

In this example, the message entry having the message ID message having a message ID "A" based on the fact that the 
"E" depends directly from message ID "D". As a result, the " root " fla S is t0 a ^ state m the database 39. The 
conversation index 118a (FIG. 4d ) for message ID "E" is conversation index 110a (FIG. 4d ) is generated for the 
generated. Next, the message entry having the message ID message having a message ID "A". After this conversation 
"F" depends direcdy from message ID "E". So, the conver- index fc generated, the conversation indices are generated 
sation index 120a (FIG. 4d ) for message ID "F" is gener- for aU the messages that depend from the conversation root, 
ated. Finally, the message entry having the message ID "G" In this example, a conversation index is generated in a 
depends directly from message ID "F". So, the conversation 30 manner previously described in connection with FIG. la for 
index 122a (FIG. 4d ) for message ID "E" is generated. a11 of the message entries. 

After all of the conversation indices are generated, the a11 of lDe conversation indices are generated, the 

conversation indices are stored in the local message store 38 conversation indices are stored in the local message store 38 
in connection with the appropriate messages. Also, the m connection with the appropriate messages. Also, the 
"dirty" flags then are set to a false state to indicate that the 35 "dirt/* flags then are set to a false state to indicate that the 
conversation indices are set for the messages, as shown in conversation indices are set for the messages, as shown in 
FIG. 76. FIG. 7* 

Referring to FIG. 7c, in the second client-server session, In a tmrd client-server session, there are three messages to 
there is only one message, namely Message 8, to be down- De downloaded. Referring to FIG. 4b, these messages 
loaded from the server 49 to the client 20. In FIG. 4b, 40 delude: Message 1 having no references in its reference 
Message 8 has a references field consisting of fi eld and having a message ID "A"; Message 4 having a 
<A><DxE>and has a message ID "H". The message is references field consisting of <A>and having a message ID 
downloaded and data fields are populated in a similar " D "i and Message 5 having a references field consisting of 
manner as previously described in connection with FIG. la. <A><D>and having a message ID "E". 
However, in this example, the message entry includes: EID 45 Referring to FIG. 7e, the message manager 37 determines 
"5", article number "200", title "Message 8", message ID that the message ID "A" is located in the database and that 
"H", parent ID "E", and posted time "Jan. 3, 1998 the message entry for message ID "A" is a place holder. 
08:00:00". A"dirty" flag is set to a true state for the message, Based on this information, Message 1 is downloaded to the 
and a "place holder" flag is set to a false state for the local message store and the appropriate data fields are 
message entry. As noted, the parent ID is the last referenced 50 populated to provide a complete message entry. Specifically, 
message ID in the references field. the title field 310 is populated with the title "Message 1" and 

As previously mentioned, the message manager checks the posted time field 325 is populated with the date and time 
each referenced message ID to determine whether there is a sent "Jan. 4, 1998 08:00:00". A "dirty" flag is set to a true 
match in the database 39. In this example, the last referenced state for the message, and a "place holder" flag is set to a 
message ID "E" is already located in the database 39, 55 false state for the message entry. In addition, all message 
thereby indicating that the ( message entry is either a place entries that depend from the conversation root having the 
holder or the message has already been downloaded. The message ID "A" are updated by changing the "dirt/' flags 
message manager 37 checks the next referenced message ID fr° m a false state to a true state, as shown in FIG. le. 
"D". Message ID "D" is also already located in the database Next, turning to FIG. If, the message manager 37 
39. The message manager 37 then checks the next refer- 60 retrieves the next message ID, namely message ID "D", 
enced message ID "A". Message ID "A" is not found in the from the server 49 and determines that the message ID "D" 
database, and therefore, a place holder is created for mes- is located in the database 39. The message manager 37 
sage ID "A". The place holder includes: EID "6", Article further determines that the message entry for message ID 
number "200", message ID "A", and no parent ID. The "D" is a place holder. Based on this information, Message 4 
message manager 37 determines that the message having 65 is downloaded to the local message store 38, and in the 
message ID "A" is a conversation root because there are no database 39, the title field 310 is populated with the title 
more referenced messages. As a result, the "root" flag is set "Message 4" and the posted time field 325 is populated with 
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the date and time sent "Jan. 4, 1998 08:01:00". The "dirty" client using an application program 36 (FIG. 2), such as the 

flag is already set to a true state for the message because the "MICROSOFT OUTLOOK '98" program. The 

message depends from the conversation root Message 1, "MICROSOFT OUTLOOK '98" program has a message 

which requires its conversation index to be regenerated. The manager program module 37 (FIG. 3), which is operative to 

"place holder" flag is changed from a true state to a false 5 communicate with the remote mail server 49 (FIG. 3). In this 

state for the message entry. embodiment, the client, the remote mail server, and the local 

Next, turning to FIG. Ig, the message manager 37 message store implement an Internet protocol and operate in 

retrieves the next message ID, namely message ID "E", from an on-line mode. 

the server 49 and determines that the message ID "E" is At start step 500, the exemplary program module is 

located in the database 39. The message manager 37 further 10 initialized and a connection is made between the client and 

determines that the message entry for message ID "E" is a the server, typically via a modem, for communication. Also, 

place holder. Based on this information, Message 5 is at start step 500, a log-in procedure typically occurs, where 

downloaded to the local message store 38, and in the a user is prompted to enter a password, and the password is 

database 39, the title field 310 is populated with the title verified by the program module. 

"Message 5" and the posted time field 325 is populated with 15 N cx t, in step 505, a command to retrieve a message ID is 
the date and time sent "Jan. 4, 1998 08:02:00". The "dirty" transmitted from the client to the server. Each message 
flag is already set to a true state for the message because the preferably has a message identifier or message ID to identify 
message depends from the Message 4, which requires its the message. In response to the command, in step 510, the 
conversation index to be regenerated. The "place holder" cli&nt retrieves a message ID from the server. Next, the 
flag is changed from a true state to a false state for the 20 message jd is compared to each message entry in a client- 
message entry. based database, in step 510, The database preferably con- 
After all of the messages have been downloaded from the tains message-related information for news messages. This 
server 49, the message manager 37 generates a conversation message-related information is maintained in the database 
index for each message entry having a "dirty" flag set to a particularly in connection with generating a conversation 
true state. The conversation indices are then stored in the 25 index for conversation threading. 

local message store 38 in connection with the appropriate A central inquiry is made, in step 520, as to whether the 

messages. Also, the "dirty" flags are set to a false state to message ID retrieved from the server matches any of the 

indicate that the conversation indices are set for the Message IDs in the database. If there is a match, the "YES" 

messages, as shown in FIG. 7h. branch is followed to step 530; otherwise, the "NO" branch 

Finally, in the fourth client- server session, there is only 30 is followed to step 525. In step 530, another inquiry is made 

one message to be downloaded, namely Message 6, which as to whether the message entry is a place holder, 

has a references field consisting of <A><D><E>and has a To determine whether a message entry is a place holder, 

message ID "F". The message manager performs a similar the message manager checks the state of a "place holder" 

procedure as previously described in connection with FIGS. ^ flag for the message. If the "place holder" flag is set to a false 

la-lh. state, the message entry in not a place holder, and the "NO" 

Referring to FIG. li, Message 6 is downloaded to the local branch then is followed to step 535. In step 535, a determi- 

message store 38 and the appropriate data fields in the nation is made as to whether there are any additional 

database 39 are populated. Specifically, the title field 310 is messages located on the server. If there are additional 

populated with the title "Message 6" and the posted time 4Q messages located on the server, the "YES" branch is fol- 

field 325 is populated with the date and time sent "Jan. 4, lowed to step 510, in which case, the next message ID is 

1998 08:03:00". The "dirty" flag is set to a true state for the retrieved; otherwise, the "NO" branch is followed to the end 

message, and the "place holder" flag is changed from a true step 575. 

state to a false state for the message entry. In addition, any If the "place holder" flag is set to a true state, the message 

messages that depend from Message 6 is updated by chang- 45 entry is a place holder, and the "YES" branch is followed to 

ing the "dirty" flag from a false state to a true state. In this step 525. In step 525, download operations are performed to 

example, Message 7 is the only message that depends from download the message from the server to the client. The 

Message 6. As a result, the "dirty" flag is changed from a process of downloading a message and setting data fields in 

false state to a true state. the database are described in greater detail below in con- 

The message manager 37 then generates a conversation 50 nection with FIG. 9. 

index for each message entry having a "dirty" flag set to a After download operations are performed, in step 527, 

true state, which in this case includes Message 6 and message entries are updated, if necessary, in the database. 

Message 7. The conversation indices are then stored in the For example, parent ID fields may be updated to reflect 

local message store 38 in connection with the appropriate changes in conversation roots, "dirty" flags may change 

messages. Also, the "dirty" flags are set to a false state to 55 states, "root" flags may change states, and so forth, 

indicate that the conversation indices are set for the After the message entries have been updated, in step 540, 

messages, as shown in FIG. Ij. a determination is made as to whether there are any addi- 

In view of the foregoing, the present invention effectively tional messages located on the server. If there are additional 

and efficiently keeps track of messages that are downloaded messages located on the server, the "YES" branch is fol- 

from a server to a client and maintains the message order of 60 lowed to step 510, in which case, the next message ID is 

a threaded conversation. Advantageously, the present inven- retrieved; otherwise, the "NO" branch is followed to step 

tion provides place holders for messages so that missing 545. 

messages do not ruin the message order. A determination is made, in step 545, as to whether there 

With continuing reference to FIGS. 1-7, FIG. 8 is a flow have been any conversation roots downloaded to the client, 

diagram illustrating an exemplary method of operation of 65 If a conversation root has been downloaded, the "YES" 

the present invention. Those skilled in the art will appreciate branch is followed to step 555; otherwise, the "NO" branch 

that this exemplary method of operation is carried out by a is followed to step 550. In step 555, a conversation index is 
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generated for the conversation root, as previously described 
in connection with FIGS. 4-7. Next, in step 570, a conver- 
sation index is generated for all reply messages that depend 
on the conversation root. If a reply message does not have 
a conversation root or no conversation roots have been 
downloaded, in step 550, a conversation index is generated 
based on the parent ID. 

Once all conversation indices have been generated, in step 
560, the conversation indices are stored in association with 
their respective downloaded messages in a local message 
store, such as a MAPI store. Next, all "dirty" flags are set to 
a false state to indicate that a conversation index has been 
generated for the respective message. The process termi- 
nates at the end step 575. 

Now turning to FIG. 9, a flow diagram illustrating an 
exemplary process of downloading a message from the 
server to the client is described. Specifically, steps 600-690 
represent the process of downloading a message and setting 
data fields in a database as described in connection with step 
525 of FIG. 8. 

In step 600, a message is downloaded from the server to 
the MAPI store located at the cli6nt. Next, in step 605, data 
fields in the database are populated with message-related 
information, such as an article number, a title, and a message 
ID for the message. The process of populating data fields is 
described in greater.detail below in connection with FIGS. 
10a and 106. Specifically, FIG. 10a illustrates the population 
of data fields for a message that does not have a matching 
message ID in the database, and FIG. 10b illustrates the 
population of data fields for a message that has a place 
holder in the database. 

Referring still to FIG. 9, once data fields are populated 
with the message-related information, a "dirty" flag is set to 
a true state in step 610. As previously mentioned in con- 
nection with FIGS. 6a and 6b, the true state of the "dirty" 
flag is indicative of a message that does not have a conver- 
sation index set in the local message store. The true state of 
the "dirty" flag is also indicative of the message being 
"dirtied" because a conversation index of another message 
from which the message depends has not been set or has 
become "dirtied". 

In step 615, a "place holder*' flag is set to a false state. The 
false state of the "place holder" flag is indicative of the 
message being downloaded and the message-related infor- 
mation for the downloaded message being populated in the 
database. 

Next, the references field of the message is checked for 
message IDs, in step 620. Each message has a references 
field that can include a single message ID, a group of 
message IDs, or no reference at all. In the case where the 
message has no reference, the message is a conversation root 
or root message. In other words, the message with no 
reference is the original message having no links to other 
messages. In the case where the message has at least one 
message ID, the message is a reply or nested message and 
is linked to any messages referenced in the references field. 

Next, a determination is made, in step 625, as to whether 
there are any message IDs in the references field of the 
downloaded message. If so, the "YES" branch is followed to 
step 635, in which case a "root" flag is set to a false state. 
The false state of the "root" flag is indicative of the message 
being a reply message and not a conversation root. If there 
is no message ID in the references field, the "NO" branch is 
followed to step 630, in which case the "root" flag is set to 
a true state. The true state of the "root" flag is indicative of 
the message being a root message or conversation root. After 
step 630, the process branches to step 527 (FIG. 8). 
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In the case where the message has at least one reference, 
in step 640, the last referenced Message ID in the references 
field is checked. This referenced message is considered the 
parent of the downloaded message. Next, in step 645, the 
5 parent ID field is populated with the last referenced message 
ID. 

Based on this referenced message ID, a determination is 
made, in step 650, as to whether the referenced message ID 
matches any of the message IDs in the database. If there is 

10 a match, the "YES" branch is followed to step 655; 
otherwise, the "NO" branch is followed to step 665. In step 
655, a central inquiry is made as to whether there are 
additional references in the references field of the message. 
If so, the "YES" branch is followed to step 660, in which 

i5 case the next referenced message ID in the references field 
is checked. It will be understood that the next referenced 
message ID is the reference located to the immediate left of 
the last referenced message ID in a tree structure conversa- 
tion threading scheme. 

20 Once the next referenced message ID is checked, the same 
determination is made, in step 650, as to whether the next 
referenced message ID matches any of the message IDs in 
the message ID field in the database. If there are not any 
additional references in the references field of the message, 

25 the "NO" branch is followed to step 527 (FIG. 8). 

In step 665, a place holder is created for the referenced 
message ID when there is not a match for the message ID in 
the database. The process of creating a place holder is 
described in greater detail below in connection with FIG. 11. 

30 Next, a determination is made, in step 670, as to whether 
there are additional references in the references field of the 
message. If so, the "YES" branch is followed to step 680, in 
which case the "root" flag for the message is set to a false 
state; otherwise, the "NO" branch is followed to step 675, in 

35 which case the "root" flag for the message is set to a true 
state. After step 675, the process branches to step 527 (FIG. 
8). 

Upon completion of step 680, the next referenced mes- 
sage ID in the references field is checked, in step 685. This 

40 referenced message is considered the parent of the non- 
downloaded message having the place holder. Consequently, 
in step 690, the parent ID field is populated with the next 
referenced message ID. Based on the next referenced mes- 
sage ID, a determination is made, in step 650, as to whether 

45 the referenced message ID matches any of the message IDs 
in the database. This entire process, steps 600-690, is 
performed for each message on the server. 

With continuing reference to FIG. 9, FIGS. 10a and 10b, 
collectively referred to as FIG. 10, are flow diagrams 

50 illustrating an exemplary process of populating data fields in 
accordance with an exemplary embodiment of the present 
invention. Referring to FIG. 10a, the population of data 
fields for a message that does not have a matching message 
ID in the database is described, where steps 700-725 rep- 

55 resent this process as described in connection with step 605 
of FIG. 9. In step 700, an entry identifier or ID is populated 
in an entry ID field in the database. Next, an article number 
for the message is populated in an article number field in the 
database, in step 705. A title for the message is then 

60 populated, in step 710, in a title field in the database. In step 
715, a message identifier is populated in a message ID field 
in the database. Next, in step 720, a parent identifier or ID 
is populated in a parent ID field in the database. Finally, a 
posted or sent time and date for the message is populated, in 

65 step 725, in a posted time field in the database. 

Turning to FIG. 10£>, a flow diagram illustrating the 
population of data fields for a message that has a place 
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holder in the database is described, where steps 730 and 735 child of the conversation when there are additional refer- 

rep resent this process as described in connection with step ences in the reference field. The process of generating a 

605 of FIG. 9. In the case where a place holder is in the conversation index terminates at the end step 950. 

database, specific message-related information has already In summary> it ^ be understood that the present inven- 

been placed in their appropriate fields. As previously men- 5 t ion provides a system for managing messages communi- 

tioned in connection with FIG. 9, the process of creating a ^ a clicnt<scfvcr architeclure , mh as a dislrib . 

place holder is described below in FIG. 11. Hence, the 4 , . . . t t , , ,. . , 

y . . . r . , j * *u j * u a »u uted computing environment represented by a client and a 

remaining information is stored in the database after the _ r *» . . r J4 i_ . 

f, j ijjr c -fin server. The present invention uses a database, stored at the 

message has been downloaded from the server. Specifically, v . , ,. e 

in step 730, a title for the message is populated in the title „ cl » ent - t0 mamtain a central arcmve ° f ^ssage-related 

field in the database. Finally, a posted time and date for the 10 ^onnaUon to support conversation threading operations 

, « , • / ■ . . fl ci i • between the client and the server. Communications with a 
message is populated, in step 735, in a posted time held in 

the database message server are facilitated by accessing a client-based 

, T „ t . . - r*r^ < m i-t^ 11 • database representing a central archive of message-related 

With continuing reference to FIGS. 1-10. FIG. 11 is a . - . a u - a • e a • *u r ♦ 

a .,, • i c mformation. Archived information is accessed in the client- 

flow diagram lUustrahng an exemplary process fo. -creating „ ^ m communications 

a place holder in accordance with an lexemplaryembcriiment ; such „ * e ™ 6ovfnlo * d operations . ^ 

of the present invention. Specifically, steps 800-825 repre- ^ foTm!llioa j, then used t0 convert m s from a tree 

sent this process as described in connection with step 665 ol , . u , 4 AT1T e . 

™^ « , onn * * j t ' c 1IA i * j * structure conversation threading scheme to a MAPI format 

FIG. 9. In step 800, an entry identifier or ID is populated in for use in a MAp[ stQre 

an entry ID field in the database. Next, an article number for 2n . ' . . 
the message is populated in an article number field in the ^ invention may conveniently be implemented m one 
database, in step 805. A message identifier or ID is or morc program modules that are based upon and imple- 
populated, in step 810, in a message ID field in the database. ment the features illustrated in FIGS. 3-11. No particular 
Next, in step 815, a parent identifier or ID is populated in a programming language has been described for carrying out 
parent ID field in the database. A"dirty" flag for the message 7 , the various procedures described above because it is con- 
is set to a true state, in step 820. Finally, a "place holder" flag sidered the operations, steps, and procedures described 
for the message is set to a true state, in step 825, thereby above and illustrated in the accompanying drawings are 
indicating that the message entry is a place holder. sufficiently disclosed to permit one of ordinary skill in the art 
Referring to FIG. 12, a flow diagram illustrating an to practice the present mvenUon. Moreover, there are many 

exemplary process for generating a conversation index 30 com P u ! ers * nd °P eratm S s y stems ^ ch ma * be 

, I i * j • r • i- ♦ u ~a practicing the present invention and therefore no detailed 

based on message-related information in a client -based r & r 1Jt u. i- 

database is described. In the start step 900, all of the computer program could be provided which would be apph- 

messages in a client-server session have been downloaded cable l ° aU of these ""J* d,ffercn, Each ° fa 

j ,i ■ ♦ c u ■ »u j . u « u particular computer will be aware oi the language and tools 

and the appropriate fields in the database have been popu- K , . , r , r L . > j j * 

i . j r Lv . *u 4 * * nnn ™ M4 / „: • which are most useful for that user s needs and purposes. In 

lated. In addition, at the start step 900, assume a message is 35 . . . . ... t . , . • * u ♦ ♦ 

, , , . , fi ,5 ♦ • ■ ™ ™„ addition, although the invention was described in the context 

selected having a references field containing only one mes- e -. j lL * 

it> *u u ■ a ' *u * ■ n of a e-mail client, mail server, and message store, that 

sage ID, thereby indicating that the message is a reply , . 1* t * . 1 *u 

0 j / * implement one of a variety of Internet protocols, those 

message and not a root message. , . tU t ... • < ,u * *u ■ • r 

^ 0 . . , r i_ • . skilled in the art will appreciate that the invention is apph- 

To generate a conversation index for the message, in step t . if . . , , t ^ rtF *T. 

f . 1 run?* * * cable to remote servers that include other types or data 

905, the message manager places a value of 1 in a first 40 * . j ci * a ■ *u 

^ , , «. , * • • j ^ n 1. c cu- stores, message stores, and file stores, and in other operating 

field of the conversation index. Typically, the first field is environments 

unused in MAPI format-sensitive applications. 

Consequently, a value of "1" is used as a default value in the t ^ternative embodiments will become apparent to those 

first field. Next, in step 910, the message manager obtains sla " ed "? the arl f whicn the V™ ni 

from the database a time and date for the root message. Ttie 45 without departing from its spirit and scope. Accordingly the 

message ID for the root message is also obtained from the of ^ e P^ esen ^ m f ventl0D » defined by the appended 

database, in step 915. Next, in step 920, the message . cla ™* rathe [ ^ ' the ^regomg description. 

manager obtains from the database a time and date for the 7? at « da«ned >s: 

reply message. Once the information in steps 910, 915, and V lD a oastnbuted computer system including a server and 

920 have been obtained from the database, in step 925, the 50 " cl : ent ' the ^ent mcluding a local message store and a 

exemplary program module stores the time and date of the database > a method for managing conversation threads based 

root message in a second field of the conversation index. on message -related mformation for a message having a 

Next, the message manager generates, in step 930, a unique m f e ^ntifier and a references field, the message- 

identifier for the root message based on the message ID of r £ laled mformation being stored in the database, comprising 

the root message obtained from the database. The unique 55 ste P s 

identifier is generated by using a "hashing" process to ( a ) during a client-server session, retrieving from the 

convert the arbitrary length of the message ID to the fixed server the message-related information corresponding 

length of a unique identification field. The unique identifier t0 tDe message; 

then is stored in the unique identification field or a third field (b) based on the message -related information, determin- 
of the conversation index, in step 935. 60 ing whether the message has been previously down- 
Next, in step 940, the message manager calculates the loaded from the server to the local message store 
difference between the time and date of the reply message located at the client; 

and the time and date of the root message to produce a (c) in response to determining that the message has not 

difference "delta" for the reply message. This difference been previously downloaded from the server to the 

"delta" is then stored, in step 945, in a fourth field. The delta 65 local message store, 

of the conversation index represents a child of the conver- i, downloading the message from the server to the local 

sation. Moreover, a delta preferably is generated for each message store, and 
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ii. populating a plurality of data fields in the database 9. The method of claim 1, wherein after generating the 

with the message-related information; conversation index for each downloaded message, the 

(d) determining whether the references field of the mes- method further comprises the step of providing an indication 

sage is empty; m tne database that the conversation index has been deter- 
ge) in response to determining that the references field of 5 m ^ d ^ r the me f a f n , . , _ 

v - ^ ° • j- „„ „a:^:^ i n t u„ 10. The method of 9, wherein the step of providing an 

the message is empty, providing an indication in the . . . , , * , , v . • , . 

., t t f t tU m • , °„„ A «, t : rtrt r ™». indication in the database that the conversation index has 

database that the message is a conversation root; , , . . 

. . been determined for the message comprises setting a dirty 

(f) providing an mdication in the database that a conver- fl t0 a fdse glate ifl lhe database , 

sation index has not been determined for the message; 1Q u ^ melhod of x whefein aftef generating the mUm 

(g) repeating the steps (a) through (f) for each remaining versation index for each downloaded message, the method 
message on the server; and further comprising the step of storing the conversation index 

(h) generating, based on the conversation root, the con- for the downloaded message in the local message store, 
versation index for each message downloaded from the 12. The method of 1, wherein the step of determining 
server to the local message store. 15 whether the message has been downloaded from the server 

2. The method of claim 1, wherein the message-related to the local message store comprises comparing the message 
information comprises the message identifier for identifying identifier for the message to at least one message identifier 
the message, an article number for identifying the number of in the database and determining whether the message iden- 
the article for the message, a title for identifying the title of tifier for the message matches the one message identifier in 
the message, and a parent identifier for identifying the parent 20 the database. 

of the message. 13. A method for generating a conversation index based 

3. The method of claim 2, wherein the message-related on message -related information for a reply message, the 
information further comprises a posted time for indicating a reply message arranged in a news conversation threading 
time and date that the message is posted to a news server. structure and including a message identifier and a reference, 

4. The method of claim 3, wherein the data fields of the 25 the reference including a message identifier for a root 
database comprise a message identification field for the message, the message-related information stored in a 
message identifier, an article number field for the article database, located at the client, and including the message 
number, a title field for storing the title of the message, a identifier and a time and date for the root message and the 
parent identification field for storing the parent identifier for reply message, the conversation index supporting conversa- 
the message, and a posted time field for storing the time and 30 tion threading so that the root message and the reply 
date of the message. message are grouped in a MAPI format for use in a MAPI 

5. The method of claim 4, wherein the step of populating format-sensitive application, the conversation index com- 
the data fields in the database with the message-related prising fields arranged in the MAPI format, the method 
information further comprises the steps of: comprising the steps of: 

populating the message identification field with the mes- 35 (a) placing a value in a first field of the conversation 

sage identifier; index; 

populating the article number field with the article num- (b) obtaining from the database: 

Der; i. the time and date for the root message, 

populating the title field with the title of the message; An the messa S e identifier for the root message, and 

. 4 , , * i # ■ c * * c i j .,u ( l , iii, the time and date for the reply message; 

populating the parent identification field with the parent . x . , , _ A _ r j ° 

-a c a. a (w storing the time and date of the root message in a 

identifier for the message; and v 7 , & „ , , . , . , & 

„ second field of the conversation index; 

populating the posted time field with the time and date of /JX . . . , 

t~t>'** 6 f ( d j generating a unique identifier based on the message 

the message. identifier of the root message; 

6. The method of claim 1, wherein the step of providing 45 . , . ° , . , _ _ . 

• • . • * ,i j * i» *u . ;* • . „. ; (e) storing the unique identifier in a third field of the 

an indication in the database that a conversation index has v 7 & . • H . 

not been determined for the message comprises setting a conversation in ex, 

"dirty" flag to a true state in the database. G> determining a difference between the time and date of 

7. The method of claim 1, wherein the step of generating, the re P l Y messa S e and lhe time and - date of me root 
based on the conversation root, the conversation index for 50 message; and 

each message downloaded from the server to the local (g) storing the difference between the time and date of the 

message store comprises: re p!y message and the time and date of the root 

t a message in a fourth field of the conversation index, 

creating a preamble based on the conversation root; and & ' 

. . . the conversation index representing the reply message in 

if the message is not the conversation root, creating a . WAm , tC . w ADT , 4 

6 - „ . ..~ j 55 the MAPI format for use in the MAPI format-sensitive 

reply message field for maintaining a difference delta lication 

defining a difference between a sent time of the mes- 1 . ' , ^ , . , . , _ 

& t . _ t . 14. The method of claim 13, wherein the reply message 

saee and a sent time or. the conversation root. . , . .. , c t . . . , t C 

oa 6 v au« a *w c has iu additional reference containing a message identifier 

8. The method of claim 7, wherein the step of creating the - , . t . ° ., ?- f 

. , , , , . r . ° for a second reply message, the message identiner for the 

preamble based on the conversation root comprises: a \ a *• jj**-*u a 

r 60 second reply message and a time and date for the second 

placing a value of one in a first field of the preamble; reply message stored in the database; and 

storing the sent time of the conversation root in a second wherein the method further comprises: 

field of the preamble; and consulting the database to obtain the time and date for 

generating a unique identifier based on the message the second reply message; 

identifier of the conversation root; and 6 5 determining a difference between the time and date of 

storing the unique identifier in a third field of the pre- the second reply message and the time and date of 

amble. the root message; and 



04/22/2004, EAST Version: 1.4.1 



US 6,330,589 Bl 

27 28 

storing the difference between the time and date of the 23. The method of claim 22, further comprising the steps 

second reply message and the time and date of the of: 

root^message in a fifth field of the conversation in responfic t0 determming that there ^ the additional 

15. l£ method of claim 13, wherein placing a value in a 5 refe 1 ren | ce f ° r the u mes f S e re P 1 ^ P rovidin S an ind ^ cation 
first field of the conversation index comprises placing a m the database that the second message is not the root 
value of "1" in the first field of the conversation index. message; 

16. The method of claim 13, wherein the step of gener- storing the message identifier for the additional message 
ating a unique identifier based on the message identifier of as the parent identifier for the second message; 

the root message comprises performing a hashing process to determitli whether the me identifier for the addi . 

convert the length of the message identifier to a fixed length. , & . , ,. 7 . , .„ . 

17. The method of claim 13, wherein the reply message £ onal messa S e 15 located m the messa 8 e identification 
has additional references each including a message identifier lne database; 

for an additional message and a time and date for the in response to determining that the message identifier for 

additional message, the method further comprising for each the additional message is not located in the message 

additional reference, determining a difference delta, delta 15 identification field, downloading into the database a 

defining the difference between the time and date of the second message entry comprising the message identi- 

additional message and the time and date of the root g er f or tne additional message from the server; and 

message, and for each additional reference, storing the . * . . . ...... . . ■ , 

,. a . u j^-.- i a u c providing an indication in the database that the second 

difference delta in an additional field of the conversation r a . , 

mdex 20 message entry is a place holder. 

1C , c j.i , . j * i * 24. The method of claim 23, wherein the step of providing 

18. A method for creating, in a database located at a client. . ,. A . . Al _ , A , ..... . • . 

, . t . e r 4 . . . an mdication m the database that the second message is not 

a place holder from a reply message that has been down- ... « a . r t 

i j i • « j » l. c i the root message comprises settmg a root flag to a false 

loaded in the database from a server, the reply message 4 4 . iL . 4 & , r to 

. . e a u r l *■ * • state in the database. 

including a references field for hosting a reference compns- ^ , c , • ~~ , . ., . c ... 

* j . a c i 4t _ f, , 25. The method of claim 22, wherein the step of providing 

ing a message identifier for a second message, the method ZD . t . \ A . . . 

, . ° L , r an mdication in the database that the second message is the 

comprising the steps of: , . 

-f,"..,, , r ^ , . f . , root message comprises setting a root nag to a true state 

(a) determining whether the references field of the reply m ^ database 

message includes the reference comprising the message 26 ^ method of daim 22> wherein tfae gtep of 

identifier for the second message; ^ generating) based on the message , a conversation 

(b) in response to determining that the reference mcludes index for the message comprises creating a preamble 
the message identifier for the second message, deter- based on the ^cond message comprising the steps of: 
mining whether the message identifier for the second , . , . ~ . - . , . , 

° . , 4 , . ° i . r a u • placing a value in a first field of the conversation index; 

message is located in a message identification held in r ° 

the database, the message identification field storing selecting an arbitrary time and date for the second mes- 

message identifiers for messages; sage; 

(c) in response to determining that the message identifier storing the arbitrary time and date of the second message 
for the second message is not located in the message in a second field of the conversation index; and 
identification field, downloading into the database a based on the message identifier of the second message, 
message entry from the server, comprising the message 4Q storing a unique identifier in a third field of the con- 
identifier for the second message; and versation index. 

(d) providing an indication in the database that the mes- 27. The method of claim 26, wherein the step of 
sage entry is a place holder. generating, based on the second message, a conversation 

19. The method of claim 18, wherein further in response index for the reply message comprises the steps of: 

to determining that the reference includes the message 45 determining a difference between a time and date of the 

identifier for the second message, storing the message iden- reply message and the arbitrary time and date of the 

tifier for the second message as a parent identifier for the second message; and 

reply message. storing the difference between the time and date of the 

20. The method of claim 18, further comprising the step rcply message and the arbitrary time and date of the 
of providing an indication in the database that a conversation 50 message m a fourth field of the conversation 
index has not been generated. index 

21. The method of claim 20, wherein the step of providing 2 8. The method of claim 18, wherein the step of providing 
an mdication in the database that a conversation index has an ind i cation in the database that the message entry is a place 
not been generated comprises settmg a "dirty" flag to a true holder comprises setting a "place holder" flag to a true state 
state in the database. 55 m the database. 

22. The method of claim 18, further comprising the steps 29 A met hod for generating a conversation index based 

on message-related information for a root message, the root 

determining whether there is an additional reference in the message arranged in a news conversation threading structure 

references field for the reply message, the additional and including a message identifier, the message-related 

reference including a message identifier for an addi- 60 information stored in a database, located at the client, and 

tional message; including the message identifier and a time and date for the 

in response to determining that there is no additional root message, the conversation index supporting conversa- 

reference in the references field for the reply message, tion threading so that the root message is converted to a 

providing an indication in the database that the second MAPI format for use in a MAPI format-sensitive 

message is a root message; and 6 5 application, the conversation index comprising fields 

generating, based on the second message, a conversation arranged in the MAPI format, the method comprising the 

index for the second message and the reply message. steps of: 
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(a) placing a value in a first field of the conversation 
index; 

(b) obtaining from the database: 

i. the time and date for the root message, and 

ii. the message identifier for the root message; 

(c) storing the time and date of the root message in a 
second field of the conversation index; 

(d) generating a unique identifier based on the message 
identifier of the root message; and 
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(e) storing the unique identifier in a third field of the 

conversation index, 
the conversation index representing the root message in 

the MAPI format for use in the MAPI format -sensitive 

application. 

30. The method of claim 29, wherein placing a value in a 
first field of the conversation index comprises placing a 
value of " 1" in the first field of the conversation index. 
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